menzel
78f012f955
Run against scan 450, the trace reported a flyback contaminating every line. It is wrong, and the file says why: samy is recorded three times per line, at 198.8163 / 198.8651 / 198.9238, and those are the same three positions in line 0, line 20 and line 43. They sit in the bottom 47% of the range and run backwards. They are scan-loop checkpoints taken after the burst and during the return -- the traverse itself is never sampled. Describing the return move as if it were the line is the wrong answer delivered confidently, which is worse than no answer. Two guards. Per line, if the samples never advance along the commanded direction, say so and name no mechanism. Globally, report what fraction of the commanded travel the readback covers and how much of it runs the right way, and stop before the span, stall and step-size numbers if the answer is none -- those describe the loop, not the stage. Repetition across lines is deliberately not the test. A healthy scan repeats too, since every line does the same thing; an earlier version tested for that and flagged all four synthetic controls. Also rank the leading channel by range over counting noise rather than range over level. On scan 450 the old score picked mca8, which sits at 2 counts and is pure Poisson, over mca6, which is the diode that formed the image and carries the artefact.
Debug scripts
Throwaway diagnostics for investigating beamline problems. Not part of the plugin:
nothing here is imported by csaxs_bec, and none of it needs BEC or a venv beyond the
libraries each script names.
Kept on the debug/scan-artefacts branch rather than main so that a half-finished
diagnostic never reaches a production checkout. Promote anything that turns out to be
generally useful; delete the rest once the question it answered is settled.
scan_artefact_check.py
Desk check for the July 2026 commissioning scan artefacts reported by Andreas Apseros and Kazu Hirosawa. Read-only — opens BEC master files and writes nothing.
python3 scan_artefact_check.py --root /sls/x12sa/data/p23080/raw/data \
--scan 473 --scan 450 --scan 411 --scan 254
Answers two questions without beam:
- end-of-line intensity — is the last point of every line systematically weaker, and is the first point affected too (which would mean a different mechanism)?
- dropped line motion — did the fast axis actually travel on every line? A line whose span collapsed is motion that did not happen while the scan still reported success.
Include a known-clean scan (254) so a null result distinguishes "this scan was fine" from "the analysis is wrong".
Run --list first if anything looks off; it dumps the file structure.
The motion check reads the fast-axis readback. If that axis is an open-loop stepper with no encoder, the readback is the commanded position and lost steps are invisible: a collapsed span still proves failure, but a healthy span proves nothing.