Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADAcquireBusy goes to 0 before camera is really done #54

Open
MarkRivers opened this issue Feb 24, 2023 · 3 comments
Open

ADAcquireBusy goes to 0 before camera is really done #54

MarkRivers opened this issue Feb 24, 2023 · 3 comments

Comments

@MarkRivers
Copy link
Member

Sebastian Eckert reported on EPICS tech-talk:

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?

@MarkRivers
Copy link
Member Author

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.

@MarkRivers
Copy link
Member Author

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.

@MarkRivers
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant