menzel
a198d2aaa5
Four scans agreed that the first point of every line loses a fixed number of milliseconds rather than a fixed fraction -- 5.18 ms at 15 ms per point, 5.36 at 20, 5.93 and 6.04 at 50 -- while the fraction itself moved from 35% to 12%. Scan 473 was the exception at 16.09 ms, and its own last/bulk of 1.207 said why: the intensity rises 20% along every line in that scan, so the whole-line mean is a biased baseline and manufactures a deficit at the low end. Both ends are now measured against their own k nearest neighbours, and the along-line trend is reported next to them so the confounder is visible rather than folded in. On a synthetic file carrying a true 6.0 ms deficit under a 20% ramp, the old baseline reported 14.46 ms and the new one reports 6.09. A channel only contributes to the summary if its deficit exceeds three standard errors over the lines. mca8 sits at two counts and was donating a meaningless 0.71 ms to the median. Positioners are also now excluded by having a setpoint rather than by their trace being monotonic. The shape test discarded any intensity that drifts smoothly along a line -- which is precisely the case that motivated this commit.
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.