Experimental Physics and
Industrial Control System

Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> · Fri, 24 Feb 2023 22:15:11 +0000

Sebastian,

I have created a Github issue https://github.com/areaDetector/ADAndor/issues/54 and a new branch that I think should fix the problem https://github.com/areaDetector/ADAndor/tree/wait_done

Please try the new branch to see if it fixes the problem.  I noticed there was an existing PR for this problem. https://github.com/areaDetector/ADAndor/pull/45
However, I think my solution is simpler and more robust, because that PR does not handle the case where the detector returns an error.

Mark

-----Original Message-----
From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Pearson, Matthew via Tech-talk
Sent: Friday, February 24, 2023 11:22 AM
To: Sebastian Eckert <sebastian.eckert at helmholtz-berlin.de>; tech-talk at aps.anl.gov
Subject: RE: [EXTERNAL] AreaDetector, order of DetectorState_RBV and AcquireBusy

Hi,

In that driver the DetectorState_RBV is updated via a function called statusTask that runs in its own thread. It monitors the detector state (using the Andor SDK function GetStatus) and the sensor temperature sensors and cooling system. The image readout is done in a different thread using a function called dataTask, which also updates the ADAcquire parameter, which controls the callback and the state of the AcquireBusy record. 

So I think it's possible that the acquisition has finished (and all the plugins have completed execution), and then AcquireBusy is set back to 0, but the DetectorState_RBV is still 1 either because statusTask has not run yet or the detector really is still busy for a few milliseconds after the image readout has been completed.

If I look at the Andor SDK user manual I see this in the section for the SDK function GetStatus:

This function will return the current status of the Andor SDK system. This function should be called before an acquisition is started to ensure that it is IDLE and during an acquisition to monitor the process

which implies that we can't start a new acquisition until GetStatus reports Idle. 

I can't remember now if I've tested sequences of ADAcquire commands with no delay in between them. However, the driver does check the ADStatus parameter (obtained from the SDK GetStatus, and which also corresponds to DetectorState_RBV) before allowing a new acquisition to start. In this case, if ADStatus is still reporting busy, it doesn't start an acquisition and it also doesn't set the ADAcquire back to zero, so the AcquireBusy record gets stuck in busy state. 

As an interim solution, a short delay between image acquisitions will help fix this problem, or also monitor the DetectorState_RBV value as you mentioned. 

Perhaps the driver should not complete image acquisition by setting ADAcquire back to 0 until the detector state also reports Idle. 

Cheers,
Matt

-----Original Message-----
From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Sebastian Eckert via Tech-talk
Sent: Friday, February 24, 2023 6:50 AM
To: tech-talk at aps.anl.gov
Subject: [EXTERNAL] AreaDetector, order of DetectorState_RBV and AcquireBusy

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System