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

docs/developer/panda_box_free_running_setup.md

@@ -2,10 +2,14 @@
 
 > **Status: Mode B confirmed working end-to-end against real PandA hardware
 > (2026-09-15, omny-panda.psi.ch)** — correct per-channel raw values, masked
-> `gate_detector_active`, and `frame_counter`-based completion all verified.
-> Config switched back to Mode A afterward for A/B comparison testing (see
-> "Switching between modes" below); re-enable `omny_panda_continuous` to test
-> Mode B again. Remaining TODO: speed testing beyond the initial 100 Hz.
+> `gate_detector_active`, and `frame_counter`-based completion all verified,
+> then speed-tested up to 20 kHz with no reported issues (though see the
+> caveat under "Saving / restoring layouts" — the saved `omny_freerun.ini`
+> layout itself was captured at 10 kHz, not 20 kHz). `ptycho_flomni.yaml`
+> currently has `omny_panda_continuous` (Mode B) active — note the PandA's
+> Design was switched back to `OMNY` on 2026-09-15 solely to capture the
+> `omny.ini` layout file below, so double-check which Design is actually
+> loaded on the physical PandA before running a scan against either config.
 
 ## Context
 
@@ -116,10 +120,33 @@ layout can be restored unambiguously (see `ptycho_flomni.yaml`):
 
 Use `ophyd_devices/devices/panda_box/utility_scripts.py` to save the current
 PandA configuration to a `.ini` layout file and reload it later, so a
-configuration survives a PandA power cycle. **TODO**: once Mode B's block
-configuration is finalized against real hardware, save it as a named layout
-(e.g. `flomni_panda_free_running.ini`) alongside the existing Mode A layout,
-and record the exact save/load commands used here.
+configuration survives a PandA power cycle. Both layouts are saved in this
+repo under `csaxs_bec/devices/panda_box/layouts/` — `omny.ini` (Mode A) and
+`omny_freerun.ini` (Mode B), captured 2026-09-15 directly from the PandA
+design named `OMNY`/`omny_freerun` respectively (switch the PandA's active
+Design first, then save):
+
+```
+python ophyd_devices/devices/panda_box/utility_scripts.py \
+    --host omny-panda.psi.ch --save-layout csaxs_bec/devices/panda_box/layouts/omny.ini
+
+python ophyd_devices/devices/panda_box/utility_scripts.py \
+    --host omny-panda.psi.ch --save-layout csaxs_bec/devices/panda_box/layouts/omny_freerun.ini
+```
+
+To restore either, swap `--save-layout` for `--load-layout` with the same
+file. Diffing the two confirms the mode-specific differences documented
+above: `PCAP.GATE`/`PCAP.TRIG` are `TTLIN1.VAL` in Mode A vs `CLOCK1.OUT` in
+Mode B; `CLOCK1.ENABLE` is `ZERO` (off) in Mode A vs `ONE` in Mode B;
+`INENC1`-`4.VAL.CAPTURE`/`FMC_IN.VAL1/VAL2.CAPTURE` are `Min Max Mean` in
+Mode A vs `Value` in Mode B; `PCAP.BITS0.CAPTURE`/`COUNTER1.OUT.CAPTURE` are
+`No` in Mode A vs `Value` in Mode B.
+
+`omny_freerun.ini` was captured with `CLOCK1.PERIOD=0.0001` (100 µs → 10 kHz)
+— note this doesn't match the 20 kHz reported as tested successfully the
+same day, so it may not be the exact layout state the 20 kHz test ran at;
+worth double-checking before relying on this file as "the" validated
+high-rate layout.
 
 ## Signal alias mapping