Re: Using subArray

[Noboru Yamamoto <noboru.yamamoto@kek.jp>]

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?