Experimental Physics and
Industrial Control System

Peter Milne <[email protected]> · Wed, 28 Mar 2012 17:30:15 +0100

On 03/28/2012 04:30 PM, Andrew Johnson wrote:

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.

Nice!, this seems more "EPICS-ish" than areaDetector and I think it

would work well for the case where the data rate is low enough for the

embedded IOC to handle the raw waveform records, then we don't have to

set up a separate dedicated data stream. areaDetector still seems like

the answer for very high data rates, and we'll be trying that as well.

So with the aSub technique, the embedded IOC spits out a raw waveform

every trigger. Somewhere on a faster host, a softIOC has a set of aSub

records with the the raw WF as input. I'd go for 16 outputs per aSub,

so, for example a 64 channel system has one input WF and 4 aSub records

to represent the channel data. Even better, it appears that in this case

the requirement is not to present the channel data as waveforms, but

rather as scalar mean value PV's; easy for the aSub support routine to

do that I guess, unless we can have a CALC record work on a Waveform,

then we could have both ..

HTH,

Sure does! Thanks a lot Andrew

/Peter
--
Peter Milne			[email protected]
D-TACQ Solutions Ltd		www.d-tacq.com

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System