Skip to content

Fold the 2-BM hexapod, timing and piezo staff answers - #634

Merged
xmap merged 4 commits into
mainfrom
worktree-fold-2bm-hxp-time-piezo
Aug 9, 2026
Merged

Fold the 2-BM hexapod, timing and piezo staff answers#634
xmap merged 4 commits into
mainfrom
worktree-fold-2bm-hxp-time-piezo

Conversation

@xmap

@xmap xmap commented Aug 9, 2026

Copy link
Copy Markdown
Owner

Folds the eight 2-BM staff answers that had been sitting unread, and fixes what checking them turned up. Closes cora#592, cora#593, cora#594, cora#595, cora#596, cora#597, cora#599 and cora#245; cora#598 was a duplicate of cora#271 and closed as one.

Every cited constant was re-read from source before folding: hexapod_reboot.py at the pinned commit, both IOC wrappers, and the two docs2bm pages. The answers were accurate. Three of them still could not be folded as written.

PIEZO-5: the cross was in the source, not the wiring

CORA had recorded the two gate-delay PVs with their axes reversed and flagged the result as a contradiction with the cable map. Staff traced the cables on 2026-07-28 and the same pass corrected item_028 itself (2bm-docs a3aa6be0): the axis comments were wrong, out2 is X and out3 is Y as the cable map always said. So the wires are unchanged and only the delay-PV association moves. The page says that explicitly, because a future reader working from a cached copy of the old page would otherwise reinstate the flag. The chain is now recorded per axis, so the PV, pin, signal and controller IP cannot drift apart again.

HXP-8: the Y-dial caution goes, the homing postcondition does not arrive

The manual post-reboot dial correction is obsolete, so the Caution is removed and the convention it described (user = dial home + OFFSET, Y at 350 / -350) becomes calibration state on the hexapod, recorded without a unit because the source gives none.

What is deliberately absent is a homing postcondition on the recipe. The pinned reboot script contains no homing step and neither IOC wrapper does, so whatever re-homes the axes was not part of what HXP-7 certified. Until it is named (new question HXP-9) the recipe records the convention but claims no homed hexapod as its own outcome.

item_050 still carries the old instruction pending a staff-side edit, so the page states that it is out of date rather than leaving the two sources to be reconciled by whoever reads them next.

HXP-4: a correct confirmation that CORA cannot act on

The IOC script names and host are confirmed. Both wrappers also open a gnome-terminal tab and run ssh -t interactively, so no headless executor can invoke them; the callable surface is the 2bmHXP.pl launcher they wrap. The recipe keeps the wrapper names, because they are what an operator runs, and gains the gap as a listed blocker.

Citations

Folding HXP-7 exposed a blob/HEAD citation that could not stay true, since every value read from that script would silently stop matching its source on the next edit. The rule added to conventions.md is not "pin everything": a navigational link wants the moving ref, and the test is whether CORA is repeating a claim. Applied to the MCTOptics citation, verified at the pinned commit first.

Also

  • TIME-2: port camera_trigger_out renamed out1, which was the fold (the old name was an explicit placeholder for the unknown channel). outTrig is recorded as the signal on the pin, not as the port name. Gate-delay blocks stay unregistered as Assets; nothing needs to address one by identity.
  • HXP-5: PDU address and outlet recorded, credentials deliberately not, and no pdu_a/pdu_b selector carried into the model.
  • HXP-6: the recipe now carries the worst-case reboot budget (~8 min) alongside the happy path, and the TCP readiness check is reclassified from optional to pending-a-value.

Staff questions go 33 rows to 27. Two new: HXP-9 (what homes the hexapod) and PIEZO-6 (whether the operator screen carries a stale axis annotation).

Verified: mkdocs build --strict clean, test_2bm_trigger_wiring.py passes after the rename, no dangling references to any retired question ID.

xmap added 4 commits August 9, 2026 13:50
The 2026-07-28 patch-panel trace (cora#245, cora#599) settled which FPGA
output drives which piezo axis, and staff commit 2bm-docs a3aa6be0
corrected item_028's delay-PV axis comments in the same pass.

CORA had recorded those comments faithfully and flagged the result as a
cable-map contradiction. The contradiction was in the source, not the
wiring: out2 is X and out3 is Y, as the cable map always said. The wires
are therefore unchanged and only the delay-PV association moves, which
is worth stating explicitly so the flag is not reinstated from a cached
reading of the old page.

Replace PIEZO-5 with PIEZO-6, which asks the one thing the doc fix
cannot answer: whether the operator screen carries a stale annotation.
The camera leg is confirmed end to end (cora#599): PSO -> MUX2-1 ->
GateDly1 -> outTrig -> FPGA out1 -> Oryx Line2.

Rename the port camera_trigger_out to out1. The old name was an
explicit placeholder standing in for the unknown channel, and the
answer supplies it; out1 also reads as a peer of out2 and out3, which
are already pin names. The staff answer suggested naming the port for
the softGlue signal instead, but outTrig is what travels on the pin
rather than the pin itself, so it is recorded as an annotation.

Record the GateDly1 PV form verbatim. Its dot-separated record fields
differ from the piezo legs' flat underscore names, so the three blocks
are peers in function and not in form; deriving any of them from a
template would invent a PV. They stay unregistered as Assets, since
nothing needs to address a gate-delay block by identity.

TIME-1 needs no fold: cora#598 is a duplicate of cora#271, whose answer
is already in beamline.yaml and the settings table. Correct the two
places that still called the gateware version pending, and keep the
box's output-channel count unknown: three pins in use is not a count.
Staff confirmed decarlof/2bmb-bin as the current production source on
2026-07-28 (cora#592-597), which settles the enable PVs, IOC scripts and
host, PDU and outlet, reboot timings, and the over-travel lockup route.
Every cited constant was re-read from the script before folding.

Pin the citation to commit 372285c6 rather than HEAD. A record that
points at a moving ref stops being a record the next time the file
changes, and that commit is the last to touch it, dated to match the
deployed copy staff compared against.

Retire the Y-dial caution. The manual post-reboot correction it
described is no longer performed; the coordinate convention behind it
becomes calibration state on the hexapod instead, which is where a
dial-to-user offset belongs. item_050 still documents the old step
pending a staff-side edit, so say so on the page: the next reader to
reconcile the two should not restore the caution from the stale source.

Do not claim a homing postcondition for the recipe. The pinned script
contains no homing step and neither IOC wrapper does, so whatever
re-homes the axes was not part of what HXP-7 certified. HXP-9 asks what
it is; the fact is recorded, the postcondition is not.

Add the headless-invocation blocker HXP-4 exposed. Both IOC wrappers
open a gnome-terminal tab and ssh interactively, so an executor cannot
call them as written and will have to reach the launcher they wrap.
Folding HXP-7 exposed a citation that could not stay true: the hexapod
recipe sourced PVs, scripts, timings and an outlet from a link to
blob/HEAD. A HEAD link means "whatever is there now", so every value
read from that file would silently stop matching its own citation the
next time the script changed, with nothing to notice.

The fix is not to pin every link. A navigational link wants the moving
ref, and pinning one sends the reader to a stale page. The rule that
actually separates the two cases is whether CORA is repeating a claim:
a record whose provenance means "whatever that file says now" is not a
record, while "see the staff page" is fine unpinned.

Apply it to the MCTOptics citation, which is the other deployment-doc
case where an external file supplies recorded values. Verified the
file at the pinned commit before citing it, per the rule's own last
line: a wrong pin is worse than a moving one, because it looks checked.
@xmap
xmap force-pushed the worktree-fold-2bm-hxp-time-piezo branch from 42319fe to 54fe0b5 Compare August 9, 2026 18:56
@github-actions

github-actions Bot commented Aug 9, 2026

Copy link
Copy Markdown

Coverage report

This PR does not seem to contain any modification to coverable code.

@xmap
xmap merged commit 6258f5c into main Aug 9, 2026
20 checks passed
@xmap
xmap deleted the worktree-fold-2bm-hxp-time-piezo branch August 9, 2026 19:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant