search

areaDetector / ADEiger

areaDetector driver for the Dectris Eiger detector
https://areadetector.github.io/areaDetector/ADEiger/eiger.html
9 stars 9 forks source link

External Series doesn't end once all images are taken #28

Closed jbhopkins closed 3 years ago

jbhopkins commented 5 years ago

Note: Issue opened based on Mark River's request on TechTalk.

This is a bug that happens in the External Series mode for the Eiger detector. I set the trigger mode to external series, and 'Start' collection. If I then send an external trigger, the series collects as expected. I can watch NumImagesCounter_RBV increment, and it reports the right number of images collected. However, after all the images are collected, Acquire stays 'Collecting'. In order to take another series I have to first click the 'Stop' button. Additionally, the StatusMessage_RBV stays as 'Waiting for external trigger' until I click the 'Stop' button.

This is in contrast to the Internal Series behavior, where at the end of a series Acquire goes to 'Done' as I would expect.

brunoseivam commented 5 years ago

This is where the current behavior was (re-)introduced: https://github.com/areaDetector/ADEiger/commit/ac9228f7853c38e584583bb342c5ebf4eda13319. There was supposed to be a blocking wait command from the SIMPLON API that would return when the acquisition is done, but I don't remember it ever working correctly.

ulrikpedersen commented 5 years ago

@GDYendell @MattTaylorDLS ?

cmkewish commented 5 years ago

@jbhopkins you say that you send 'an' external trigger: I'm reading that you expect the series to be completed after 1 trigger and N images?

Is the parameter 'ntrigger' ("$(P)$(R)NumTriggers") set to 1 in that case? If so, has the final datafile been closed as if the detector had disarmed itself at the end of the series? This could be tested by setting nimages_per_file ("$(P)$(R)FWNImagesPerFile") to a value larger than nimages ($(P)$(R)NumImages).

What happens if you then send another trigger? I would expect the detector not to respond, if it has disarmed itself.

Edit: this comment is more related, I suppose, to the operation of the detector itself, rather than EPICS interaction with it...

jbhopkins commented 5 years ago

@cmkewish Yes, for this test I was using 20 images and 1 trigger as my exposure settings. I had the number of images per file set to 1000. I don't know how to tell if the final datafile is closed, however the detector doesn't respond to further triggers, just the first.

cmkewish commented 5 years ago

@jbhopkins If you send 1 trigger, and 20 images are captured into a datafile that has number of images per file 1000, you can tell that the detector has disarmed itself at the end of the 20 images if the data file is already available in the DCU_IP/data directory. If the detector is no longer responding to triggers that is probably the case, which means the detector state changed without EPICS' knowledge.

I think the same thing would happen if you started an acquisition series with areaDetector and then sent an ABORT command directly to the detector another way e.g., via the RESTful API. I had a similar problem using the Dectris python API to control the detector in a kind of 'focus mode' between scans using areaDetector to collect data within the beamline scan system: that is, PVs did not reflect the state of the detector if it changed due to something happening outside of EPICS.

MattTaylorDLS commented 5 years ago

Yes @brunoseivam, there isn't a blocking wait command on the API that could be used to determine when the detector has finished. As we don't use the internal data file, but collect data directly from the ZMQ stream, we couldn't rely on seeing when the file is closed, or when NumImagesCounter reaches the expected value, therefore it's up to our control software to determine when it's finished, and so the stop can be pressed to disarm the detector ready for the next acquisition.

MarkRivers commented 3 years ago

I have partly fixed this issue in the upcoming R2-8. This is from the RELEASE.md file.