Folks,
Ø
I also added a dbpf command at the end of the st.cmd files to force the AcquireTime record to process. This fixes the problem with AcquireTime and autosave in this issue:
Ø
https://github.com/areaDetector/ADEiger/issues/58
I have reverted that fix and instead used the info tag asyn:READBACK on the AcquireTime, AcquirePeriod, and ThresholdEnergy records in eigerBase.template. This updates the output records, not just the RBV records, whenever the driver changes
one of these parameters. This means there is no longer any inconsistency because the actual value in use and the value in autosave, so the next reboot should restore the actual current settings.
Mark
From: Mark Rivers
Sent: Thursday, May 12, 2022 3:17 PM
To: Miceli, Antonino <amiceli at anl.gov>
Cc: tech-talk at aps.anl.gov
Subject: RE: Alignment mode for AreaDetectors?
Folks,
I have now implemented TriggerMode=Alignment for the Eiger. When acquisition is started in alignment mode it caches the value of NumImages and sets it to 1. It then collects images one at a time in a loop until acquisition is stopped.
When acquisition is stopped it restores the cached value of NumImages.
This allows what Nino was asking for, continuous acquisition without needing to change NumImages or NumTriggers. This is the output of camonitor on the ArrayCounter_RBV record. It shows that the overhead is about 0.8 seconds, so the fastest
update rate is just over 1 Hz. This may be fine for many applications.
corvette:~/devel/areaDetector/ADEiger>camonitor -tci 13EIG2:cam1:ArrayCounter_RBV
13EIG2:cam1:ArrayCounter_RBV (2022-05-12 14:59:00.363489) 0
13EIG2:cam1:ArrayCounter_RBV ( +2.273435) 1
13EIG2:cam1:ArrayCounter_RBV ( +0.844454) 2
13EIG2:cam1:ArrayCounter_RBV ( +0.827992) 3
13EIG2:cam1:ArrayCounter_RBV ( +0.784932) 4
13EIG2:cam1:ArrayCounter_RBV ( +0.815482) 5
13EIG2:cam1:ArrayCounter_RBV ( +0.825144) 6
13EIG2:cam1:ArrayCounter_RBV ( +0.812477) 7
13EIG2:cam1:ArrayCounter_RBV ( +0.792468) 8
13EIG2:cam1:ArrayCounter_RBV ( +0.775525) 9
The new code on the “alignment_mode” branch on Github:
https://github.com/areaDetector/ADEiger/tree/alignment_mode
It seems to work fine in my limited testing. Please try it and if it works I will make a new release.
I also added a dbpf command at the end of the st.cmd files to force the AcquireTime record to process. This fixes the problem with AcquireTime and autosave in this issue:
https://github.com/areaDetector/ADEiger/issues/58
Mark
Hi Nino,
In principle that mode could be implemented in ADEiger. It would effectively be the same as setting TriggerMode=InternalSeries, NumImages=1, NumTriggers=1, and setting Acquire=1 as soon as the previous image is complete.
The only issue is the performance. This is the output of camonitor on the Acquire PV when I do that manually on an Eiger2S 1M with AcquireTime=0.01 seconds.
corvette:~>camonitor -tci 13EIG2:cam1:Acquire
13EIG2:cam1:Acquire ( +7.574912) Acquire
13EIG2:cam1:Acquire ( +0.775277) Done
13EIG2:cam1:Acquire ( +1.491137) Acquire
13EIG2:cam1:Acquire ( +0.789318) Done
13EIG2:cam1:Acquire ( +1.194118) Acquire
13EIG2:cam1:Acquire ( +0.807242) Done
13EIG2:cam1:Acquire ( +0.530099) Acquire
13EIG2:cam1:Acquire ( +0.798572) Done
13EIG2:cam1:Acquire ( +0.623805) Acquire
13EIG2:cam1:Acquire ( +0.780007) Done
So it takes about 0.8 seconds to acquire a single frame even with a very short acquire time. If this is done instead with a large value of NumImages and setting Acquire=1 only once then the update rate is basically limited by the AcquireTime.
Mark
I think the issue is that former users of the Pilatus really used the Alignment frequently and now are using the Eiger which is slightly different.
I think what they really like is the ability to leave alignment running for a very long time (~hours) without having to make NumImages very large.
Hi Nino,
Ø
The Pilatus detector had a popular mode called alignment which came with the detector SDK; essentially this mode would overwrite to the same file and continue until the stop button was pressed.
That mode is not part of the SDK, it was something I created in the ADPilatus driver. All it does is to set NumImages=1 and to tell camserver to keep writing to the same file called “alignment.tif”. It reads back the data from alignment.tif
and does callbacks to all registered plugins, just as for regular data collection mode.
Ø
Is there a clean/easy way to emulate this for other areadetectors? (I know I can disable all the file writing plugins.)
There is no need to disable the file writing plugins, although you would probably want to disable AutoSave in each file plugin if that is enabled. But that is no different than the ADPilatus in alignment mode: if AutoSave is enabled for
a file plugin when using the ADPilatus driver then files will be written even in alignment mode.
Perhaps I am not understanding the question. What is it that works for you with the ADPilatus in alignment mode that does not work with other detectors, and which detector in particular are you asking about? As Mark E. said if you are
using a driver that always writes files then you can just disable auto-increment to avoid creating many files.
Mark
The Pilatus detector had a popular mode called alignment which came with the detector SDK; essentially this mode would overwrite to the same file and continue until the stop button
was pressed.
Is there a clean/easy way to emulate this for other areadetectors? (I know I can disable all the file writing plugins.)