Files
csaxs_bec/AGENTS_mirko.md
T
x12saandClaude Sonnet 5 7fe20ea3d1
CI for csaxs_bec / test (push) Failing after 2m55s
docs: add note-location rule and OMNY tomo_alignment_fit TODO to AGENTS_mirko
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-21 16:22:54 +02:00

4.1 KiB
Raw Blame History

Personal notes — mirko

Personal working notes for Claude Code sessions in this repo, for my own use across machines. Not project-wide guidance — nothing here applies to other contributors, and nothing else in this repo references or enforces it.

Repo ownership boundaries

Root causes traced into BEC core (bec_lib/bec_server/bec_ipython_client, the bec repo) or into core bec_widgets are not mine to fix here — those are owned by their respective core teams. When an investigation in csaxs_bec turns up a bug whose fix belongs in one of those repos, write it up (a short report or plan) instead of implementing/committing it there.

Fixes that land in csaxs_bec itself (beamline plugin code, widgets, device configs, scans) are mine to implement, commit, and push directly.

Where notes go

Never write plans, TODOs or notes to Claude's local memory / local plan files (they are machine-local and invisible on other machines). Put them in this file, or in a markdown file in the repo when I ask for one.

TODO

  • 2026-09-21: port "always define tomo_alignment_fit" from Flomni to OMNY. Flomni is done (commit 5b688df): reset_tomo_alignment_fit() writes zeros instead of deleting the global var, and ensure_tomo_alignment_fit() (called from Flomni.__init__) creates the zero fit only if missing, so manual tweaks like fit[0][2] += 5.0 work. OMNY (omny/omny_alignment_mixin.py) still deletes the var and never defines it at startup; nothing in omny/ calls the reset yet, so decide where OMNY should reset it. LamNI does not use it. Details and steps: csaxs_bec/bec_ipython_client/plugins/omny/AI_docs/TODO_tomo_alignment_fit_always_defined.md.

  • 2026-09-20: flomni_fermat_scan hung on pre_scan_all_devices() after positions were already sent to the rt controller (scans 11998, 12000 in /var/log/bec/ScanServer.log / DeviceServer.log). Positions/PID-correction step (prepare_setup_part_2()) completed fine; kickoff()/start_scan() (the actual rt-side trigger, logged as Read N out of 106) was never reached because the joined pre_scan_all_devices() wait never returned. No error, no timeout — DeviceServer just went silent until manually aborted. Most likely culprit: omny_panda_continuous (PandaBox) — on_pre_scan() in ophyd_devices/devices/panda_box/panda_box.py:696 arms the PCAP block and returns a status that only resolves on a PandaState.READY/FRAME/END event, with no timeout. Logs show Cannot emit async signal omny_panda_continuous_data ... with status aborted spamming throughout the hang window, consistent with the box being left in a stuck/unarmed state after the preceding rapid interlock-triggered abort/retry cycle (11991–12001, ~11 attempts in 5 minutes). This traces into ophyd_devices, not csaxs_bec — per the ownership note above, not mine to fix directly here. Follow-ups to consider: (a) file/flag this with whoever owns ophyd_devices (add a timeout + explicit failure path to PandaBox.on_pre_scan's status callback so a stuck arm surfaces as an error instead of hanging forever), (b) check whether on_unstage/_reset_panda() is reliably called on scan abort so the box doesn't carry a stale state into the next attempt.

    Status 2026-09-20 (csaxs_bec side done): PandaBoxOMNY.on_pre_scan (csaxs_bec/devices/panda_box/panda_box_omny.py) no longer waits for READY forever. Each arming attempt waits pre_scan_timeout (default 5 s); if READY does not arrive, the box is force-reset (_reset_panda()), the readout thread restarted and arming retried once (retry is printed and logged as a warning with diagnostics). Only if the second attempt fails as well does the status fail with a RuntimeError, so the scan aborts instead of hanging. Still open for the ophyd_devices owner: the base-class race where the readout loop's finally: _reset_panda() can clear data_thread_run_event after a fresh on_stage() set it (likely root cause of the missing READY after rapid abort/retry); the new diagnostics line in the DeviceServer log (data_thread_run_event=False) would confirm it.