Hi Peter,
On 2012-03-28 Peter Milne wrote:
Maybe it's quite easy to do this outside the IOC (eg with Python Channel
access), but ideally it would happen inside an IOC so that it's
completely transparent to a client. The Subarray record is an obvious
choice, but it appears to take a contiguous block of data, there doesn't
seem to be a concept of a stride value.
eg assuming the Waveform Record refers to data
[samples][channels] with dimension (typical) [1024][96], the extract
routine needs to run through the data set with a stride of 96.
It looks like subarray could be used to extract [sample-N][:] but not
the required [:][channel].
A possibly simpler alternative to using Mark Rivers' areaDetector module might
be to use an aSub record and write your own C code that it runs to extract the
samples for each channel. A single aSub record has 21 output value fields
(which can be configured as arrays of any of the basic types) so it's easy to
see how to extract up to 21 channels from the input waveform. However it is
also possible to use some of the input fields as outputs, so it should be
feasible to have one aSub record handle a nice round 32 channels and still
leave enough input fields for some configuration values.
I'm not trying to steer you away from areaDetector which is great for doing
complicated real-time processing on camera images and other 2-D data, but if
you already have an EPICS driver that populates the waveform record, just
writing an aSub subroutine would probably involve less software development
effort. If you decide to go this route you would need to call db_post_events()
on the input channels you set to trigger Channel Access monitors on those
fields.