Read the interlock's outcomes without adopting its shape - #591
Merged
Conversation
BLEPS-1/2/3 came back from 2-BM (#562, #563, #564). Two confirmed what CORA assumed: every latching fault is either a shared utility or one named device, and all 385 signals are readable over Channel Access from the soft IOC deployed 2026-07-14 under `2bmBLEPS:BLEPS:`. The third corrected us: there IS a beamline-level state operators act on as a whole, and it latches. The correction is taken; the suggested model is not. Staff proposed a system-level "BLEPS Health" object, and its load-bearing argument is the two reset PVs, which have no home on Supply or Asset because they act across many at once. But those are writes into the interlock, and CORA does not write there. Its read side already asks that question in the pre-flight check, which folds BLEPS through the composite upstream permit; the three severity aggregates refine that read below the permit's threshold rather than becoming a state of their own. And the acknowledgement the reset stands for is already modelled: a Supply an observation drove down waits in Recovering for a person to say it is back. Two other places the PLC's boundary is not CORA's. The valves keep being read as vacuum despite BLEPS owning each fault per-valve, because an Asset is for a thing whose identity someone needs and nobody has needed a gate valve's; the failing valve is named in the Supply's reason instead. The M1 tank thermocouples move the other way, onto the Mirror, because three thermocouples on one tank describe one device, not a resource many devices draw on: a cooling failure then reads as the Supply falling and, separately, as the mirror it cooled running hot. Cooling water and vacuum become beamline-scope rather than facility utilities. The answers show both cut into circuits named for 2-BM optics, which is this beamline's shape, not the site's. One Supply each, not one per circuit, until a run-readiness decision first differs by circuit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Coverage report
This PR does not seem to contain any modification to coverable code. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Folds the BLEPS answers 2-BM sent back on 2026-07-16, the only new staff answers since the June batch. Closes #562, closes #563, closes #564.
What staff said
BLEPS-1 (#562) and BLEPS-2 (#563) confirmed what CORA assumed. Every latching fault is either a shared utility or one named device, and all 385 signals are readable over Channel Access from a soft IOC deployed 2026-07-14 under
2bmBLEPS:BLEPS:, with PLC dots translated to underscores.BLEPS-3 (#564) corrected us. There is a beamline-level state operators act on as a whole, three severity aggregates plus two system-wide resets, and warnings latch.
Where this diverges from the recommendations
Staff proposed a dedicated "BLEPS Health" object. This takes the correction and declines the object, for reasons written out in full on the issue.
The load-bearing argument for the object is the reset PVs: they act across many channels at once, so they have no home on Supply or Asset. But they are writes into the interlock, and CORA does not write there, the same posture it holds toward the PSS. The read side already has a home in
BeamAvailabilityLookup, the point-in-time pre-flight port that exists for exactly this shape and already folds BLEPS through the composite upstream permit; the three aggregates refine that read below the permit's threshold. And the acknowledgement the reset stands for is already modelled, asRecoveringplus an operator-only restore on the latched-alarm precedent. So the answer changed the design without adding the object.Three smaller places the PLC's boundary is not CORA's:
TEMP1_TRIPtoTEMP3_TRIPmove to theMirror. Three thermocouples on one tank fail staff's own criterion for the utility bucket. It also keeps the FLOW2-then-hot-mirror chain legible at two layers instead of one.Scope change
Cooling water and vacuum move from facility-scope to beamline-scope. The answers show both cut into circuits named for 2-BM optics, which is this beamline's shape rather than the site's. One Supply each, not one per circuit, until a run-readiness decision first differs by circuit. 19-BM's BLEPS-1 assumption line, which says "following 2-BM", is updated to match.
Verification
make docs-build --strictclean, and one pre-existing dangling anchor removed along the way. The 952 tests undertests/unit/deploymentspass.🤖 Generated with Claude Code