ABORT/CANCEL missing, ADEiger support for EIGER2?
cmkewish opened this issue · 21 comments
Hi Bruno, Mark,
I noticed for the original EIGER that there are available API commands "ABORT" and "CANCEL" for stopping exposure series in progress, which don't seem to be supported in areaDetector.
Also, I will be receiving an EIGER2 at the end of the month at the Australian Synchrotron, and I have seen that Dectris added features such as a second energy threshold to output 2 simultaneous images.
Wondering if there has been any discussion about support for EIGER2 in areaDetector: do you have plans for including EIGER2 into ADEiger, or creating a new plugin, at this stage?
Thanks,
Cameron Kewish
Hi,
The API wrapper in this repository exposes both abort and cancel:
ADEiger/eigerApp/src/restApi.cpp
Lines 342 to 350 in 173a7b8
Abort is used here, when an ongoing acquisition is stopped:
ADEiger/eigerApp/src/eigerDetector.cpp
Lines 406 to 414 in 173a7b8
When this was written, the semantics of these commands were that cancel would stop the acquisition after the current image is finished, while abort would stop immediately. I chose abort because if you have the Eiger configured to be externally triggered, stop the external triggers and then call cancel, ADEiger would hang.
If EIGER2 has the same API as EIGER(1?), it is already supported. New features exclusive to EIGER2 can be added to this repository behind a (runtime?) feature gate. Mark can tell you if he already has plans for this; I don't have access to Eigers anymore, so I wouldn't be able to develop new features like these. Pull requests are certainly welcome!
Thanks Bruno. Your choice of abort makes good sense, thanks for the explanation.
The API commands are the same for EIGER2 for the most part, so I would expect that we can operate the new detector with basic functionality using ADEiger as we have it installed. [I believe the Monitor interface has slightly changed in that they now support both TIFF and NumPy array output and the image type has to be specified in the image request. This has at the moment broken our 'online' viewer applications.]
Hi All,
We are currently running Eiger2s at DLS with this branch: https://github.com/dls-controls/ADEiger/commits/1.8
The 1.8 API has very much been in flux since we got the detector in September. There are currently still some workarounds that we are waiting on updates to be able to take out, so it is not something that can be merged yet. I can tidy up this branch and rebase on the latest master for @brunoseivam and @MarkRivers to take a look at. There are also a few fundamental differences that I believe Dectris are not planning to rectify, so I think it will need some 1.8 specific templates and some version checking in the driver.
@GDYendell do you know if they plan to release 1.8 for the older Eigers? If so, we can make 1.8 a requirement for using ADEiger. That was my approach in the past when 1.5 / 1.6 was in flux and I didn't want to maintain feature gates in the code.
@brunoseivam that would make it much easier. We get the feeling that they are not planning on backporting 1.8 to Eiger1. They are visiting DLS next week so we can ask about that.
Just pushed some more updates to the 1.8 PR after rebasing on the latest master.
- A new bit_depth_type parameter has been added
- A load of parameters were added back in, mostly detector metadata
- The access_mode parameter metadata has been fixed, so it doesn't have to assume everything is RW anymore.
@GDYendell - thanks Gary, I have installed that and all seems to be happy. I don't use most of those metadata but it's nice not to have as many white boxes on the MEDM screen 👍
Just wondering what's the reason for changing $(P)$(R)FWNamePattern to a waveform that reports a list of integers representing ASCII character values, rather than leaving it as a string?
I think Mark did that so that the string could be longer than 40 characters.
That is correct. What command is showing it as a list of integers, rather than as a string?
Understood: thanks for the clarification Mark.
The MEDM window for ADEiger was showing '115' in the text entry field for FWNamePattern when I started the ioc. The readback value was 's'. The default startup value for the FileWriter name_pattern configuration upon Eiger initialize should be 'series_$id', so perhaps only the first character was making it into the PV?
If I enter any string into the text entry field to change FWNamePattern, there is a red error pop-up window. But, entering an integer works, say entering 100 results in a readbackvalue of 'd'. Changing 100 to 102 switches the readbackvalue to 'f'.
From the linux commandline: caget SR05ID01EIG1:cam1:FWNamePattern gives me a list of 256 space-separated integers, mostly zeros.
I've rolled back to the previous PR WIP:1.8 which I had installed, for now, because our scanning system is sending strings to the FWNamePattern PV which we parse into folder structures for data routing once the data comes off the DCU.
From the linux commandline: caget SR05ID01EIG1:cam1:FWNamePattern gives me a list of 256 space-separated integers, mostly zeros.
You need to do
caget -S SR05ID01EIG1:cam1:FWNamePattern
The -S tells caget to treat it as a string.
areaDetector uses waveform records for all file paths and file names, and they work fine with medm.
Thanks Mark -- I've changed out beamline scan system to write waveforms.
For the ADEiger MEDM window I needed to add a format="string" line to get the FWNamePattern text entry box to take and display user input as strings:
/beamline/epics/support/areaDetector/ADEiger/eigerApp/op/adl
(base) [ics@SR05ID01EIGER02 adl]$ diff -U 5 eigerFileWriter.adl eigerFileWriter.adl.orig
--- eigerFileWriter.adl 2019-05-24 13:39:18.442937062 +1000
+++ eigerFileWriter.adl.orig 2019-05-24 13:38:59.256026444 +1000
@@ -146,11 +146,10 @@
control {
chan="$(P)$(R)FWNamePattern"
clr=14
bclr=51
}
- format="string"
limits {
}
}
"text update" {
object {
For the ADEiger MEDM window I needed to add a format="string" line to get the FWNamePattern text entry box to take and display user input as strings:
Sorry, yes that is needed. I have pushed a new version that fixes that.
For information: I commented in the PR WIP:1.8 that the IOC crashes if I turn on the Monitor mode using the ADEiger MEDM window.
#27 (comment)
Also, I notice that it take about 30 s exactly to arm the detector every time, where from the RESTful API it usually only takes 30 s on the first arm after INITIALIZE, whereas successive ARMs with the same configuration only take 1 s.
For information: I commented in the PR WIP:1.8 that the IOC crashes if I turn on the Monitor mode using the ADEiger MEDM window.
#27 (comment)
Also, I notice that it take about 30 s exactly to arm the detector every time, where from the RESTful API it usually only takes 30 s on the first arm after INITIALIZE, whereas successive ARMs with the same configuration only take 1 s.
Just to be clear:
- What version of ADEiger are you running?
- What firmware do you have?
- What model Eiger do you have?
I'm running ADEiger version with changes for API 1.8.0 included in "pull request WIP 1.8" from @GDYendell at Diamond
Firmware = eiger_fw_version: "integration-19.6.21.54194-ga4b949e17"
Model: EIGER2 X 1M
Are you able to run your detector with the master branch?
If so, do the 2 issues you mentioned above occur on the master branch of ADEiger, or only on the PR?
What's the status of this issue? I'm planning to use the ADEiger driver to control an EIGER2 X 9M. Should I use the master branch or the latest release?
This issue is getting obsolete. The master branch should now support both Eiger1 and Eiger2, and support nearly all of the functionality of the Eiger2 (dual energy thresholds, etc.).
I am going to close this issue. If there are problems with the master branch please open a new issue.