2 Commits

Include renames

Author	SHA1	Message	Date
menzelandClaude Opus 5	90358f5222	debug: make the scan check work out its own geometry, or say why it cannot ... First run against real data (S00473, S00254) found the files but stopped at "metadata: none of the expected keys found" and "could not work out the line geometry". Two wrong assumptions, both now fixed. **Metadata location.** It was looked up at two hard-coded paths. BEC nests this differently across versions, so it is now found by searching the tree for the keys by basename, attributes included. Verified against metadata one level deeper than the original code expected. **Which signal defines the geometry.** The point count was taken from the *longest* signal. Real files hold signals of several lengths -- S00473 has 86884 points in something while the per-point arrays are shorter -- so a monitor on its own clock hijacked the calculation. It now takes the length shared by the most signals, since per-point data outnumbers everything else. When the geometry still cannot be inferred, the script no longer just gives up and asks for --list. It now prints every signal grouped by length, and the factor pairs that could plausibly be (lines x points-per-line). That turns a dead end into a readable diagnosis in one run rather than a round trip. If a length does not factor usefully at all it says so explicitly, because a padded or truncated per-point array is itself a finding. Also wires up --lines/--points, which were declared but never reached the analysis. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-25 09:59:03 +02:00
menzelandClaude Opus 5	a5035d91cb	debug: add a desk check for the July 2026 scan artefacts ... Read-only analysis of BEC master files, to test two user reports from the 15-20 July commissioning beamtime without needing beam. **End-of-line intensity** (Andreas Apseros): reshapes each monitored signal into lines and reports the last point and the first point against the interior mean. It only calls it the reported bug when the *last* point is short and the first is not -- if both ends are low that is a different mechanism, and the script says so rather than confirming what we went looking for. **Dropped line motion** (Kazu Hirosawa's reading, that the stage intermittently stopped scanning in one direction): reshapes the fast-axis readback and reports the travel per line. A collapsed span is motion that did not happen while the scan still reported success -- the same shape as the silent-completion defects already recorded against ccm_energy and the ECMC limit writes. It also reports start/end scatter per line, since scatter at one end only would instead point at the return move racing the next line. Verified against synthetic files with both artefacts injected and a clean control. That test caught a real flaw in the first version: the fast axis was picked by within-line range, and a noisy diode channel out-ranged the axis and was selected instead, breaking both checks. It now scores signals by how monotonically they ramp within a line, which separates an axis from an intensity regardless of scale. Lives on a debug branch, not main: it is a diagnostic for one investigation, not plugin code. bin/debug/README.md says what that means. Caveat carried in both the docstring and the README: the motion check reads the readback, so on an open-loop stepper without an encoder a healthy span proves nothing. That is the same question as Ana Diaz's micro-stepping point and needs settling before the null result means anything. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-25 09:24:27 +02:00