search

areaDetector / ADEiger

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

Problem interrupting a scan #39

Open MarkRivers opened 3 years ago

MarkRivers commented 3 years ago

@cmkewish reported the following

Hi @MarkRivers

An issue I ran into was the EIGER2 X 1M detector failing to correctly disarm when trying to interrupt a running series of exposures.

We run a mode that we call "freerun" scans where we set (in the API language) the trigger mode to manually-triggered internal series, with ntriggers = 1 and, e.g., nimages = 2 * [number of expected pixels needed in a scan], and then let the detector time it's own acquisitions, and send a disarm at the end to close the series. The master file ends up containing a ton of empty data links at the end but this is fine.

This was working prior to 2020.1 (I think) but when I asked Dectris about it they suggested to add a cancel or an abort command before disarm? The first one will stop the data acquisition after the current image is completed, while the second command would stop any acquisition immediately.

Is it included (or possible to include) into this ADEiger version to send CANCEL then DISARM when issuing a Acquire=0?

Thanks, Cameron

MarkRivers commented 3 years ago

I am trying to reproduce this problem, and so far I cannot.

I am running the master branch of ADEiger as of December 28. I have not made any changes that should affect this issue.

I am running an Eiger2 500K with the 2020.2 firmware (actually a pre-release of 2021 with extg trigger mode support, but I don't think that matters).

I have set the following PVs

image

Here is what I observe:

These are the files created in 4 tests. They are all different sizes because I stopped the acquistion after different numbers of frames.

-rw-r--r--   1 epics     domain users     319095 Dec 28 18:12 test_108_master.h5
-rw-r--r--   1 epics     domain users   40005445 Dec 28 18:12 test_108_data_000001.h5
-rw-r--r--   1 epics     domain users     319095 Dec 28 18:12 test_109_master.h5
-rw-r--r--   1 epics     domain users    8425285 Dec 28 18:13 test_109_data_000001.h5
-rw-r--r--   1 epics     domain users     319095 Dec 28 18:13 test_110_master.h5
-rw-r--r--   1 epics     domain users   12635973 Dec 28 18:13 test_110_data_000001.h5

I am then able to repeat the process.

@cmkewish is there some setting I am missing that will cause the problem you reported?

MarkRivers commented 3 years ago

I also tested with AcquireTime and AcquirePeriod=0.01 so it was doing 100 frames/s. I set NumImages=1000, so the entire acquisition would take 10 seconds. I aborted after a few seconds, and again I did not have any problem.

cmkewish commented 3 years ago

OK thank you @MarkRivers - I will update to the latest version and re-test, and let you know. Thank you for investigating.

cmkewish commented 3 years ago

Hi @MarkRivers

I wanted to install this ADEiger earlier, but only had firmware release-2020.1 which conflicts with the dependencies listed in the RELEASE.md -- But today I have updated the firmware of my Eiger2 X 1M to release-2020.2.1 and then installed the latest ADEiger version. The IOC starts fine, with a couple of error messages that seem to be non-critical, listed below the test results.

After I carried out the "Restart detector application/INIT/Restart Calibration/INIT" procedure to avoid the "null" response from calls to photon_energy as detailed in another Issue:

I followed your test procedure above, although in my test Stream is disabled, and Data Source is set to None.

I observed the following behaviour:

I have tried this also with AcquirePeriod 0.01 s with NumImages 1000 and I was able to stop the exposure using the Stop button to set Acquire=0 after about 5 seconds, and the data file size was roughly half of that from allowing the 10 s.

--> So, I think this issue is probably OK to close with a note that StatusMessage is not changing during the acquisition.

At the same time I have also noticed that there are some parameters that aren't being set when running st.cmd:

RestApi::get: [param=nexpi] server returned error code 404
2021/02/23 15:53:58.821 Param[NEXPOSURES]::baseFetch: [param=nexpi] unable to parse json response
[]
2021/02/23 15:53:58.821 Param[NEXPOSURES]::fetch<int>: [param=NEXPOSURES] underlying baseFetch failed
RestApi::get: [param=extg_mode] server returned error code 404
2021/02/23 15:53:58.901 Param[EXT_GATE_MODE]::baseFetch: [param=extg_mode] unable to parse json response
[]
2021/02/23 15:53:58.901 Param[EXT_GATE_MODE]::fetch<int>: [param=EXT_GATE_MODE] underlying baseFetch failed

Are these just due to the pre-release features you were integrating? I'm not using multiple exposures per image, so I can probably deal with ignoring these errors for now.

Cheers, Cameron