You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
There is a race condition. andorCCD:dataTask sets ADAcquire=0 does callParamCallbacks before the detector is guaranteed to have reported that its status is ASIdle or some other state than ASAcquiring. This can cause a new acquisition to attempt to start before the previous one is truly finished. This results in the observed problems.
There is an existing PR #45 that seems to address this problem.
Before I saw that PR I created a different fix which is simpler and does not require creating a new event flag. The existing PR also assumes that the detector state will switch to ADIdle, and will not behave correctly if the returned status is an error rather than ASIdle.
My fix is in the wait_done branch. Please test to see if it fixes the problem.
The previous version did not work because the dataTask was not releasing the lock. Rather than rely on the statusTask to poll the detector state the new version now does this directly in the dataTask.
Sebastian Eckert reported on EPICS tech-talk:
The text was updated successfully, but these errors were encountered: