Experimental Physics and
Industrial Control System

Carl Lionberger <[email protected]> · Wed, 30 Nov 2005 09:13:42 -0800

I think the thing to do would be to separate out the soft support for
the subarray record from the rest of the record; it really is too
closely coupled now. Then whatever buffering it uses to deal with the
outside could be in the device support code which would be tailored as
needed.
Carl
Noboru Yamamoto wrote:
Hi,
Carl Lionberger wrote:
The thought was that the subarray record would be purely a soft
record, and any hardware device support would be for waveform records
that the subarray would read from. The MALM code makes sense in this
context because the API for the dbaccess (as Noburu alluded to)
always starts at element 0 of the source record. Therefore it is
impossible to index an element larger than the buffer space you have.

In the case of a module which have more memory than the main memory on
CPU board, you might want access part of memory using a subarray record.

But the subarray record does not allow it.
We wanted to divide a very long waveform into several small waveforms so

that we can monitor it on medm/dm2k. In this case, we need O(N * N) size

of buffer memory for EPICS database, where N is a size of source
waveform. Using the compact subarray record, it can be reduced to O(N)
buffer size.
As Carl pointed out, the specification of the SubArray records is a
result of the dbaccess API. In other words, if the dbaccess library

have had an API which allow access to a part of waveform data, we

would have another specification of the SubArray record.

( And it could be quite similar to our compactSubArray record.)

--
Carl Lionberger
Control System Software Engineer
Berkeley National Laboratory (LBNL)
(510)486 7503

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System