Re: pyepics: Strategies for working with fast-changing large arrays

[Matt Newville <newville@cars.uchicago.edu>]

Hi Andrew, Anton, Mark,

On Wed, Jan 11, 2012 at 11:30 AM, Andrew Johnson <anj@aps.anl.gov> wrote:
> Hi Anton,
>
> On 2012-01-11 Anton Derbenev wrote:
>> When I add a callback for a PV object with array
>>  data within, I become "subscribed" to the entire array. The problem may be
>>  that, as described below, the PV image data is always seen as large as (in
>>  my case) 1228800 elements array, while the actual region of interest size
>>  can be much smaller (all irrelevant elements of the array simply being set
>>  to 0). So, is it possible to create the PV object and the callback for it
>>  that will only monitor the specified part of itself (like, I assume,
>>  camonitor -# does)?
>
> Assuming that you're using EPICS Base version 3.14.12.1 or later the
> underlying CA library and IOC server do support variable length arrays, but I
> don't know if or how pyepics handles them.  When calling the underlying CA
> library directly from C code if you request an array of zero elements in a
> get-callback or monitor request, you'll get sent the number of elements that
> currently appear in the IOC's array field with no zero padding added.  This
> approach is what the camonitor program uses, and if pyepics supports it you'll
> want to use this feature for maximum throughput of array data.
>
> Note that cainfo reports the size of the storage allocated for the array on
> the IOC, which is the maximum size the array can be.  It can't tell you how
> much data the array currently holds.
>

Yes, pyepics does support variable length arrays (when using
3.14.12.1).  A monitor will return the array without zero-padding if
only a portion of the array has changed.    If a PV is monitored,  a
pv.get() will also return the shortened array.   The PV should also
report the shorter number (NORD) for its 'count', while the full array
size (NELM) is in the 'nelm' field:

   >>> import epics
   >>> p = epics.PV('Py:double64k')
   >>> print len(p.get())
   65536
   >>> p.put(range(20))
   >>> print p.get()
   [  0.   1.   2.   3.   4.   5.   6.   7.   8.   9.  10.  11.  12.  13.  14.
     15.  16.  17.  18.  19.]
   >>> print p.count, p.nelm
   20 65536
   >>> print p
   <PV 'Py:double64k', count=20/65536, type=double, access=read/write>


If a PV is not monitored (which would be the default for large arrays,
though Anton has said he was explicitly setting them to be monitored),
 a pv.get() without specifying the count will return the full array,
possibly zero-padded.   But, if you do specify a count  with something
like  'pv.get(count=20)' it will pass that along to
ca_array_get_callback, and so also get the truncated array and
presumably much faster.

I have verified that using the areaDetector PVs   cam1:MinX,
cam1:MinY, cam1:SizeX, and cam1:SizeY (note: not the ROI values, but
those of cam1) does limit the array size of image1:ArrayData, and that
pyepics will see the appropriately reduced-sized array.    So, I think
that should work for Anton, provided he's using 3.14.12.1.

For arrays of up to about 1Mb at 5Hz or so, I get nearly ideal data
rates from a 1360x1024 Prosilica camera.  Above that, and for fast
data acquisition (say,  more than a few Hz), I do see dropped
callbacks, as Anton reports.  I haven't looked into this in great
detail, but it looks to me like the Python callback function passed to
ca_create_subscription() is not being called for every event.  I don't
know what is limiting that.

Cheers,

--Matt