7 Commits

Include renames

Author	SHA1	Message	Date
x01dcandClaude Sonnet 5	7d21c0e43e	docs(panda): note proposed gated-continuous PCAP capture variant ... Record the exposure-active-gated PCAP.gate variant discussed for reducing idle-time data volume in raw_stream_mode (currently PCAP free-runs via CLOCK1 regardless of detector state). Documentation only -- not implemented or tested against hardware. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0132KBoxsovfcMNRGJhS1Pbw	2026-09-19 09:11:31 +02:00
x12saandClaude Sonnet 5	acdca82137	docs(flomni): save the confirmed Mode A/Mode B PandA layouts ... Captured 2026-09-15 directly from the omny-panda hardware via GetState() (ophyd_devices/devices/panda_box/utility_scripts.py), one per Design: omny.ini (Mode A) and omny_freerun.ini (Mode B). Mode B was speed-tested successfully up to 20 kHz same day, though the saved omny_freerun.ini itself reflects CLOCK1.PERIOD=0.0001 (10 kHz) -- flagged in the setup doc as a discrepancy to double-check rather than assumed away. Setup doc updated with the exact save/load commands and a diff summary of the two layouts' mode-specific differences (PCAP.GATE/TRIG source, CLOCK1.ENABLE, capture types). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsfqLcPWspjJ6vedMyCxco	2026-09-15 15:30:10 +02:00
x12saandClaude Sonnet 5	f82fd51a72	fix(flomni): comment out omny_panda_continuous, enabled:false wasn't enough ... Both omny_panda and omny_panda_continuous ended up connected and active simultaneously against the same physical PandA, even though only omny_panda was enabled: true -- a device already connected apparently doesn't disconnect just because a later config reload disables it. Comment the inactive mode's block out entirely instead of relying on enabled: false, so BEC never constructs the device object at all. Docs updated to correct the earlier (wrong) guidance that toggling enabled alone was sufficient to switch between modes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsfqLcPWspjJ6vedMyCxco	2026-09-15 15:04:59 +02:00
x12saandClaude Sonnet 5	6415db0e2d	config(flomni): switch panda config back to Mode A, record Mode B success ... Mode B (omny_panda_continuous) confirmed working end-to-end against real PandA hardware on 2026-09-15: correct per-channel raw values, masked gate_detector_active, and frame_counter-based completion all verified. Switching back to Mode A (omny_panda) for A/B comparison testing. Both device entries now stay uncommented in ptycho_flomni.yaml, toggled via enabled: true/false, rather than commenting/uncommenting blocks -- confirmed a disabled device is an inert placeholder that BEC's device server never connects to. Speed testing Mode B beyond the initial 100 Hz is still TODO. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsfqLcPWspjJ6vedMyCxco	2026-09-15 15:02:57 +02:00
x12saandClaude Sonnet 5	f93e591227	feat(flomni): split omny_panda into two devices, fix free-running completion check ... Mode A (per-gate aggregate) and Mode B (continuous raw-sample) need different PandA hardware layouts and can't run simultaneously, so omny_panda is now two device config entries in ptycho_flomni.yaml: omny_panda (legacy, kept commented as the restore reference) and omny_panda_continuous (raw_stream_mode: true, enabled). Also fixes on_complete for the continuous case. PCAP.CAPTURED can't be used to detect end-of-acquisition on this layout: CLOCK1 drives PCAP.gate/trig continuously, so the captured count never naturally stops increasing while armed -- the previous settle-based wait would have just run out its timeout. COUNTER1 (frame_counter) instead counts completed exposures directly (triggered on the detector-trigger's falling edge), so PandaBoxOMNY now waits for it to reach the exact expected num_points * frames_per_trigger, mirroring the legacy exact-count check instead of guessing when capture has "settled". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsfqLcPWspjJ6vedMyCxco	2026-09-15 14:22:28 +02:00
x12saandClaude Sonnet 5	3012cd3154	fix(flomni): mask gate_detector_active to its own bit, record confirmed PandA wiring ... TTLIN1 (detector trigger) drives both COUNTER1 (frame_counter) and the PCAP.BITS0 gate-bit capture, confirmed 2026-09-15 against the omny-panda hardware via TTLIN1.VAL.CAPTURE_WORD?/OFFSET? (PCAP.BITS0, bit 0). PCAP.BITS0 is a shared 32-bit word -- other captured bit_out signals may occupy other bit positions of it, so the raw word is not itself a clean 0/1. PandaBoxOMNY now masks gate_detector_active down to bit 0 before publishing it, instead of trusting the whole word. Also records the confirmed free-running setup in the developer docs: all four encoders plus both FMC_IN channels switched to raw Value capture, CLOCK1 driving continuous PCAP gate/trig, and the initial 100 Hz test rate. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsfqLcPWspjJ6vedMyCxco	2026-09-15 14:13:22 +02:00
x01dcandClaude Sonnet 5	82ecab4c21	feat(flomni): add continuous free-running raw-sample mode to PandaBoxOMNY ... Adds an opt-in raw_stream_mode to omny_panda alongside the existing per-gate averaged burst acquisition, so a burst window can instead be captured as continuous raw samples plus a detector-gate bit and a monotonic frame counter for completeness checking. Client-side coalescing bounds the message rate to the BEC message bus regardless of PandA's own network-frame batching, and completion uses a settle-based check since an exact expected sample count isn't predictable for continuous capture. Defaults to off, preserving today's behavior exactly; hardware wiring/layout and the raw data schema are documented under docs/developer/ pending PandA hardware access to configure and validate against. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-15 13:44:07 +02:00