Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4.1 KiB
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 (commit5b688df):reset_tomo_alignment_fit()writes zeros instead of deleting the global var, andensure_tomo_alignment_fit()(called fromFlomni.__init__) creates the zero fit only if missing, so manual tweaks likefit[0][2] += 5.0work. OMNY (omny/omny_alignment_mixin.py) still deletes the var and never defines it at startup; nothing inomny/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_scanhung onpre_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 asRead N out of 106) was never reached because the joinedpre_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()inophyd_devices/devices/panda_box/panda_box.py:696arms the PCAP block and returns a status that only resolves on aPandaState.READY/FRAME/ENDevent, with no timeout. Logs showCannot emit async signal omny_panda_continuous_data ... with status abortedspamming 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 intoophyd_devices, notcsaxs_bec— per the ownership note above, not mine to fix directly here. Follow-ups to consider: (a) file/flag this with whoever ownsophyd_devices(add a timeout + explicit failure path toPandaBox.on_pre_scan's status callback so a stuck arm surfaces as an error instead of hanging forever), (b) check whetheron_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 waitspre_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 aRuntimeError, so the scan aborts instead of hanging. Still open for the ophyd_devices owner: the base-class race where the readout loop'sfinally: _reset_panda()can cleardata_thread_run_eventafter a freshon_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.