@sureshnaps writes:
with bp.rel_scan when using an areadetector, i would like to use it in a mode:
- let us say there are N points in the scan
- currently areadet cam1 and file capture is set to 1 for each point of the scan and triggered after each move is done, this is tons of overhead and N files are created per scan
- spec ccdscan was powerful, one can have M points from data point, many use cases for that
- what i would like to do:
- Set up cam1 to take
N*M frames, same with the file capture to take N*M frames
- after each data point move, have a hook function that is user defined which will handle how the M (>=1) are taken, could be external hardware triggered or internal software trigger supported by eiger for example
Can this be implemented? Even if ver-1 forces M=1 would be a big step. This will be a step between how it is done now and fly scanning but more closer to fly scanning in performance.
Another thing i noticed is, when a scan is started, it takes a few seconds before the scan really starts, do we understand what the delay is due to?
My general peeve is we (not necessarily everyone) are using bluesky just the way spec was running, in some cases with less features but of course BS is faster, so would like to improve where possible
@sureshnaps writes:
with
bp.rel_scanwhen using an areadetector, i would like to use it in a mode:N*Mframes, same with the file capture to takeN*MframesCan this be implemented? Even if ver-1 forces M=1 would be a big step. This will be a step between how it is done now and fly scanning but more closer to fly scanning in performance.
Another thing i noticed is, when a scan is started, it takes a few seconds before the scan really starts, do we understand what the delay is due to?
My general peeve is we (not necessarily everyone) are using bluesky just the way spec was running, in some cases with less features but of course BS is faster, so would like to improve where possible