Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: pyepics: Strategies for working with fast-changing large arrays
From: Anton Derbenev <anton000cool@yahoo.com>
To: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 23 Dec 2011 01:38:53 -0800 (PST)
Hello all,


recently I have tried to make a Python application using Epics Channel Access for Python.

I am using an EPICS areaDetector to operate a Prosilica digital camera, from which I need to rapidly obtain several images.

Getting a single PV waveform data snapshot itself is not an issue and works just fine the way it is described in the pyepics documentation.

Although a call to PV.get(...) for 1280x960x12bit data array blocks the program execution for too long (relatively to camera FPS), I've managed to get rid of any delay from my software by utilizing a multiprocessing Python interface to avoid Global Interpreter Lock.

Thus, my application is capable of running several data handling functions simultaneously without blocking.


That's where the bad part starts: when the PV that holds the image data is set to be automatically monitored (auto_monitor = True), the callback invocation happens too slow.

For example, when the camera is triggered and makes, like, 5 shots in one second, the callback for corresponding PV only runs three times! 
:(

I tried both "high-level" (PV object) and "low-level" (channel access contexts) approaches trying to make the callback calling to be faster, but no luck.


I assume that every time when the automatically monitored PV changes, its status is requested ( like in PV.get(...) ) and then passed as argument to the callback function.

So if a CA (channel access) does not allow rapid subsequent queries to a single PV, hence the delay that limits the amount of callbacks that can be called per second, this amount being less then my camera's FPS.

If this is so, then setting the auto_monitor to False and simply polling the PV with desired frequency will not work either (also this approach causes large amounts of unnecessary network traffic).


Thanks to the mighty areaDetector software, I have found the workaround (omitting EPICS at all), but it involves the file system of the hardware where the IOC runs, thus being not completely satisfactory.


Hereby I require aid: what are the strategies for working with fast-changing large data arrays using pyepics? 
How can I make my camera frame data PV object to invoke callbacks fast enough or, if it is not possible, what are other ways to save and later access the value of such PVs using EPICS?

 
Best regards,
Derbenev Anton.


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

Navigate by Date:
Prev: Re: Change to RULES.Db between 3.14.8.2 and 3.14.11 -I../O.Common no longer in include paths Andrew Johnson
Next: Re: pyepics: Strategies for working with fast-changing large arrays Matt Newville
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Australian Synchrotron Employment Opportunities Controls Lou Corvetti
Next: Re: pyepics: Strategies for working with fast-changing large arrays Matt Newville
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·