Experimental Physics and
Industrial Control System

Noboru Yamamoto <[email protected]> · Wed, 30 Nov 2005 09:01:16 +0900

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.)

You might consider writing a device support suite which supports a
waveform record of the length you want and a couple of ao or longout
records which control the index and length of the reference into the
hardware..
Carl

I completely agree with Carl on using a waveform and a soft subArray
record, if your can read entire data into a waveform record and you just
need one subarray at a time.
It is quite dangerous to use non standard API in dbaccess and a non
standard record. But you can cross boarder anytime as you like but your

own risk ( That is what I have done!).
Sometime this adventure may broaden the territory of the EPICS, I hope.
Regards,
Noboru

Michael Abbott wrote:
I am writing device support for a subArray record so that I can read
small slices from a very large array provided by a device. The device
in question has limited memory, and so I cannot afford more than one
copy of this array in memory, namely the copy in the device driver
itself. My plan is to read the data like this:
    record(subArray, "SA")
    {
        field(DTYP, "My driver")
        field(INP,  "my driver's arguments")
        field(MALM, "1024")
        field(FTVL, "LONG")
    }
    $ caput SA.NELM 1024
    $ caput SA.INDX 1024000
    $ caput SA.PROC 0
    $ caget SA
Unfortunately there is one very interesting and annoying fly in the
ointment. In subArrayRecord.c:readValue we see the following two
lines of code:
    if (psa->indx >= psa->malm)
        psa->indx = psa->malm - 1;
Ooops. Most unhelpful!
This stupid code means that MALM, which is used to allocate the
storage used by the subArray record, also determines the maximum index
into the device array. I think this is missing the point of a
subArray; it certainly gets in my way.
Now, it turns out I am lucky: malm is used to allocate storage
*before* it calls my init_record, so I can fake malm back to the value
I want to to be. However, this is hardly very satisfactory, and is
going to have a mildly embarassing side effect:
get_{graphic,control}_double will return bogus values for the upper
limit on nelm.
Any thoughts on this?

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System