Re-validate the June 2026 staff-answer batch (#238-#271) against current sources

[xmap]

Why

The June 2026 staff-answer batch (#238 through #271, almost all filed 2026-06-20/21) is where most of what CORA records about 2-BM came from: per-energy curves, part numbers, serials, drawings, stripe maps, window counts, piezo identity. Those values were folded without recording which version of the source they came from, because the citing convention that requires it did not exist yet.

That matters because an answer can be overtaken by a later edit to the source it cited, and nothing announces it. Two from that batch already were, and both surfaced only because something else brought us back to them:

• PIEZO-5: 1024 = NV200D arbitrary-waveform-generator max buffer size (default n=256 at 2-BM); current operational mode is --random; FPGA-output-to-axis cable mapping still needs operator confirmation #245 (PIEZO-5) documented a contradiction between the NV200D cable map and the gate-delay PV labels. item_028 was corrected on 2026-07-28 (2bm-docs a3aa6be0), so the issue body now describes a cross that no longer exists, and CORA had recorded the wrong half of it faithfully for six weeks.
• ENERGY-7: channel-cut crystal calibration IS current practice; #256 (ENERGY-7) was corrected by its own author within hours. The body is wrong about the "offset" mechanism; the truth is in the first comment.

Neither was found by looking. Both were found by accident.

What is already known good

The 2026-08-09 sweep behind #626 read all 75 PV names in deployments/2-bm/beamline.yaml from arcturus: 70 answered, 4 did not, and three of those four were answers already on record that had simply never been applied to the descriptor. That is reassuring about the batch and unflattering about our folding, and it is the right kind of check.

It validated PV names only. The numeric and identity payloads from the same batch have never been re-read against their sources.

Scope

Re-validate the values folded from #238-#271 against their current sources. Rough shape of what is out there, not yet a complete inventory:

• Energy curves (ENERGY-1: real store_0 per-energy positions for the three energy-tracked DMM motors (dmm_us_arm=2bma:m30, dmm_ds_arm=2bma:m31, dmm_m2_y=2bma:m32); Mono 6 energies + Pink 4 energies; source: energy2bm.json #249 ENERGY-1, ENERGY-2: real store_0 per-energy positions for B-station sample-slit vertical pair (b_slit_top=2bma:m9, b_slit_bot=2bma:m10); Mono 6 energies + Pink 4 energies (parked wide open); source: energy2bm.json #250 ENERGY-2, ENERGY-3: saved per-energy table (energy2bm.json store_0), with linear interpolation between bracketing calibrated energies for off-table requests; no Bragg-angle computation anywhere in the IOC #252 ENERGY-3), sourced from energy2bm.json store_0 in decarlof/energy. The largest payload: ~144 numeric literals in test_2bm_energy_curves_setup.py alone, across the DMM Bragg arms, m2_offset_y, and the B-station slit pair, for 6 Mono and 4 Pink energies. store_0 is edited in place by energy add every time someone recalibrates (per ENERGY-7: channel-cut crystal calibration IS current practice; #256's correction), so this is the payload most likely to have moved.
• Mirror stripe map and Pink positions (MIRROR-1: yes to both details in the description #259 MIRROR-1, MODE-3: Pink-mode per-energy m3 + table-X positions confirmed + completed (all 4 energies); stripe-to-position map below; this is the "data half" of MIRROR-1 / cora#259 #262 MODE-3). Note MODE-3: Pink-mode per-energy m3 + table-X positions confirmed + completed (all 4 energies); stripe-to-position map below; this is the "data half" of MIRROR-1 / cora#259 #262 is still open.
• DMM stripe geometry (ENERGY-6: DMM substrate carries two multilayer stripes (13.8 Å and 24 Å, 4 mm apart); details in the description #255), including the active_stripe: 24.0 inference in the descriptor.
• Optics inventory: Be window count and thicknesses (BEAM-2: 3 Be windows in the front-end / beam-conditioning stack, total Be thickness 0.63 mm (W4-20 = 0.25 mm + W4-60 = 0.13 mm + unlabelled = 0.25 mm); per-window inventory below #246), shutter and mask drawings (BEAM-3: P6-50 safety shutter has reference drawing 41050401-410003 (shutter element) and 41050401-500000 (overall P6-50 assembly); source: APS_2191941 row 10 #247, ALIGN-2: confirmed as the **M3-24 front-end exit mask** (RSS tag 02-BM-A-F-01, drawing 4102020101-240000, OFHC copper, water-cooled, fixed); #264), diagnostic flag geometry (FLAG-1: DiagnosticFlag (2bma:m44) sits in 2-BM-A at z = 32500 mm; full per-energy Y lookup (mono) + Pink parked Y = 0 mm; source of truth is energy2bm.json key energy_move_flag #251).
• Piezo identity (PIEZO-1: NV100D is NOT in operational use (decommission OpticsFineDrive); NV200D holds the coded aperture at z=51,300 mm in 2-BM-B and should be renamed CodedApertureFineDrive #241-PIEZO-4: NV200D IPs confirmed — X axis = 10.54.113.126, Y axis = 10.54.113.125; architecture is TWO separate NV200D units (one per axis), not one dual-channel controller #244): NV200D/NV100D roles, actuator part, controller IPs.
• Foil paddles (FOIL-1: downstream paddle bindings confirmed but m18 motor is currently failed, parked at 107.19 mm; upstream paddle (m17) IS operational, filter selection still available #238, FOIL-2: upstream foil paddle (2bma:m17) IS fully in service — cora's "bound in software but not in service" assumption was wrong; m18 currently failed (FOIL-1 / cora#238), m17 is the operational filter selector at 2-BM today. #240), where FOIL-1: downstream paddle bindings confirmed but m18 motor is currently failed, parked at 107.19 mm; upstream paddle (m17) IS operational, filter selection still available #238 recorded m18 as failed and parked. Worth knowing whether it was repaired.
• 16 descriptor lines carry an explicit #2xx citation; the folded values without one are the harder half and need finding rather than grepping.

Method

For each value, read the current source and compare. Where it still matches, record the source version alongside it per the citing convention, so the next pass is a diff rather than a re-read. Where it does not, fold the correction and say what changed.

Most of this needs no operator time: energy2bm.json, docs2bm, and the vendor datasheets are all readable directly. Reserve staff questions for what the sources cannot settle, per the questions-page charter.

Depends on

#624 (CAM-1). If 2bmSP1: is retired rather than merely outside arcturus's address list, the camera identity and sensor facts from the same era (#142, DET-8) describe hardware that is not installed, and the sweep should cover them too.

Not in scope

Re-asking staff to confirm what they already confirmed. The batch was accurate when it was given; this is about whether CORA's copy has drifted from a source that moved, which is CORA's problem to check and not theirs to answer again.

[decarlof]

On the two operator-only items in scope for the re-validation sweep:

FOIL-1 (#238) — 2bma:m18 foil paddle: unchanged. Still mechanically jammed; the filter cannot be changed. The original answer (m18 failed / parked) is still current, so no re-fold is needed on the CORA side.

CAM-1 (#624) / DET-8 — 2bmSP1:: still installed and operational. It is one of the two cameras on top of the Optique Peter (the other is 2bmSP2: = Oryx 31MP). The two together are the current MCTOptics Camera 0 / Camera 1 pair on the beamline.

The reason 2bmSP1: did not show up on the 2026-08-09 sweep is that its areaDetector IOC was simply off at scan time. This is a normal steady-state at 2-BM: both camera IOCs (2bmSP1: Oryx 5MP and 2bmSP2: Oryx 31MP) run on the same host (tomdet), and we conservatively only leave running the IOC of the camera currently in use — the two are cycled to keep tomdet's memory footprint low. Starting the 2bmSP1: IOC (via the standard ~/bin/detector_IOC_oryx_5mp.sh wrapper) would have surfaced the PV set on the sweep.

So the DET-8 / #142 records describe currently installed hardware, not uninstalled hardware; the sweep scope does not need to expand to cover them as retired.

PIEZO-5 (#245) — already resolved on the docs side. The underlying cable-map vs. GateDly PV contradiction was cleaned up in 2bm-docs on 2026-07-28:

• Commit a3aa6be0: docs(item_020, item_028): document FPGA-out to NV200D X/Y axis mapping (out2→X, out3→Y). Fixes the swapped # X axis delay / # Y axis delay PV comments in ops/item_028.rst and adds a per-axis table (Axis / NV200D IP / FPGA out / softGlue delay PV, verified physically at the patch panel that day) to the NV200D block of manual/item_020.rst.
• Sibling commit 8cbafd6: docs(ops/item_060, img): document GateDly-2/-3 driving the two Jena piezo stages. Adds the operator-facing softGlue how-to with the three verification screenshots.

CORA can re-fold PIEZO-5's cable-map from those two commits directly; nothing further from the operator side.

ENERGY-7 (#256) — the corrected answer is in the first comment. The original issue body still describes the "offset" mechanism the wrong way; the follow-up comment on the same issue (from the same author) walks that back and describes the actual energy add mechanism (calibration table energy2bm.json store_0 updated in place, no separate offset state stored). If useful for the re-read, that comment is the authoritative version.