Experimental Physics and
Industrial Control System

Hi,

we are using AreaDetector with an Andor IKON usb 2.0 camera. Acquisitions are triggered with a monitor on the AcquireBusy field and wait for plugins enabled which should guarantee that the camera and all connected routines are done before a new acquisition is triggered (the only active plugins are image and the HDF5). Frequently we have cases where AcquireBusy has returned already to zero after an acquisition, while the DetectorState_RBV is still 1. This condition is present for roughly 10ms.

In these cases a new trigger sets AcquireBusy to 1 while DetectorState_RBV eventually goes to zero after the completed (previous) acquisition. A fresh camera image is not taken and AcquireBusy stays 1 until aborted manually.

As a workaround, we can also monitor DetectorState_RBV to guarantee it is 0 before triggering a new acquisition.

Is this behavior expected, or should the scenario AcquireBusy=0 and DetectorState_RBV=1 not be possible?

Best
Sebastian

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Replies:

RE: [EXTERNAL] AreaDetector, order of DetectorState_RBV and AcquireBusy Pearson, Matthew via Tech-talk

Navigate by Date:

Prev: Support with EPICS-based applications Chitra Venkataraman via Tech-talk

Next: Periodic scan Issue with PV record scan type as IO Intr Arnab Dasgupta via Tech-talk

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  <2023>  2024 

Navigate by Thread:

Prev: AW: [External] Support with EPICS-based applications Chitra Venkataraman via Tech-talk

Next: RE: [EXTERNAL] AreaDetector, order of DetectorState_RBV and AcquireBusy Pearson, Matthew via Tech-talk

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  <2023>  2024