Open cmazzoli opened 6 years ago
tacaswell
commented
6 years ago I think the solution here is to A) always do the first round of motor motion before opening the run in the 'standard' scans which will delay the staging until as late as possible and B) make sure that the re-set motion happens after the scan is closed.
cmazzoli
commented
6 years ago Hi Tom, It sounds beautiful to me. Thanks. Are we supposed to do it locally or are you going to change things at a general level? Please let me know. Thank you. Claudio
On Mon, Apr 9, 2018, 00:12 Thomas A Caswell notifications@github.com wrote:
I think the solution here is to A) always do the first round of motor motion before opening the run in the 'standard' scans which will delay the staging until as late as possible and B) make sure that the re-set motion happens after the scan is closed.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/NSLS-II/Bug-Reports/issues/193#issuecomment-379625356, or mute the thread https://github.com/notifications/unsubscribe-auth/AKjlFroZ9On2--3TvdwEFDUQ78x1JEkgks5tmt-3gaJpZM4THpe8 .
tacaswell
commented
6 years ago These are changes we should do at the library level.
Our fccd has a delicate (thermal, noise, background, ...) equilibrium. Typically a scan requires the staging of the detector as a first operation before anything else is done. This put our detector out of its comfortable continuous readout as it waits for its time to be called by count (idle + multiple). Unfortunately, the waiting time before the experimental station is in the conditions of counting (motors can be slow..) is sometime considerable with the result that the detector is made uselessly waiting already staged. Would it be possible to postpone the staging of the detector AFTER the first position for the scan is reached?
Just to give you an idea, we can program the detector for a series of useful measurements taking one a fraction of a second each. Sometimes to move slow motors in position can require minutes. This makes the detector staged for more than 6 minutes to acquire few seconds of data in case the motor slowness and its backlash at the beginning (and at the end in a relative scan!) are important. See #100511 for example (RE(rel_scan(dets,sx,-.1,.1,3)) )
Perhaps a solution could be to add a
prep=Trueflag which would move the motors to the start position before staging, here. Note that in relative scan the same problem happens on the way back, where the detector should be unstaged just AFTER the last acquired point.I would really appreciate if a discussion can be started on this issue. Thanks!