GV-1: which BLEPS per-valve record is the canonical open/closed state for GV1-GV3?

[xmap]

Question

The 2-BM descriptor models the three gate valves as Vacuum Supply status (vacuum_isolation), and carries them today as bare tags [GV1, GV2, GV3] rather than as PVs. The BLEPS IOC exposes many records per valve:

GVn_CLOSED_LS      GVn_OPENED_LS       GVn_FULLY_CLOSE    GVn_FULLY_OPEN
GVn_CLOSED_SWITCH  GVn_OPENED_SWITCH   GVn_BOTH_SWITCH    GVn_NO_SWITCH
GVn_FAULTED        GVn_OPEN_PERMIT     GVn_CLOSE_PERMIT   GVn_TYPE
GVn_OPEN_COMMAND   GVn_EPICS_OPEN      GVn_EPICS_CLOSE    GVn_BEAM_EXPOSURE

Which of these reflects the physical valve position an operator would act on? Specifically:

1. Is GVn_CLOSED_LS (limit switch) the position of record, or is GVn_FULLY_CLOSE the one to trust?
2. What do GVn_BOTH_SWITCH and GVn_NO_SWITCH indicate? Presumably contradictory or absent switch feedback, but that is a guess.

Context

Read from arcturus on 2026-08-09. 2bmBLEPS:BLEPS:BIV_CLOSED returns GOOD, so the naming convention established in BLEPS-2 (#563) is confirmed working against the deployed IOC. A bare 2bmBLEPS:BLEPS:GV1_CLOSED does not exist; only the suffixed variants above do.

CORA assumes

One per-valve boolean "closed" reading is enough for Supply(kind=Vacuum) status, with the failing valve and its cause named in the Supply transition's reason, per BLEPS-1 (#562).

[decarlof]

Canonical position PV per valve: 2bmBLEPS:BLEPS:GVn_CLOSED_LS and 2bmBLEPS:BLEPS:GVn_OPENED_LS. These are the raw limit-switch inputs from the physical valve. Everything else in the per-valve set is either a diagnostic overlay (fault flags), a control-side signal (permits, commands, EPICS write PVs), or configuration (GVn_TYPE). Grouping below follows the BLEPS PV-inventory tables in manual/item_025.rst (Inputs / F
aults / Outputs / Display / EPICS_Inputs).

Position of record

Use GVn_CLOSED_LS and GVn_OPENED_LS. From the BLEPS Inputs table:

PV	Meaning	1 =
GVn_CLOSED_LS	Closed-limit switch input	Valve is at closed limit
GVn_OPENED_LS	Opened-limit switch input	Valve is at opened limit

For a Supply(kind=Vacuum) status the natural mapping is:

• isolated (valve closed) ← GVn_CLOSED_LS == 1 && GVn_FAULTED == 0
• not isolated (valve open) ← GVn_OPENED_LS == 1 && GVn_FAULTED == 0
• transitioning ← both _LS PVs are 0 and GVn_FAULTED == 0 (valve mid-motion between limits; expected while a command is in progress)
• faulted ← GVn_FAULTED == 1, with the per-cause fault flag(s) below naming the reason

Do NOT use GVn_FULLY_CLOSE / GVn_FULLY_OPEN for position

Despite the names, these are fault flags, not position sensors. From the BLEPS Faults table:

• GVn_FULLY_CLOSE = "Fail To Fully Close" (Fault code 10n7) — the valve was commanded to close but did not reach the fully-closed limit within the expected time; goes TRUE on failure, not on success.
• GVn_FULLY_OPEN = "Fail To Fully Open" (Fault code 10n4) — same, on the open direction.

These belong on the fault side of the model, not the position side. Confusing them with position would invert the meaning (TRUE = valve failed to reach that limit, not TRUE = valve is at that limit).

What GVn_BOTH_SWITCH and GVn_NO_SWITCH indicate

Both are switch-integrity fault flags in the BLEPS Faults table:

• GVn_BOTH_SWITCH — both the closed AND opened limit-switch inputs are asserted simultaneously. Physically impossible for a mechanical gate valve to be at both extremes at once, so it flags a wiring, switch, or signal-integrity fault. Fault code 10n1.
• GVn_NO_SWITCH — neither limit-switch input is asserted. Allowed transiently while the valve is in motion between limits, but should not persist; if it does it flags a switch power, wiring, or sensor fault. Fault code 10n9.

Along with GVn_CLOSED_SWITCH and GVn_OPENED_SWITCH (individual-switch inconsistencies), these four together cover the switch-integrity fault surface for each valve. All feed into GVn_FAULTED (aggregate), which is the summary boolean CORA can use for the "faulted?" test.

Full per-valve PV taxonomy (for CORA's model)

Grouped by role:

Position (Inputs) — read for state of record:

• GVn_CLOSED_LS, GVn_OPENED_LS

Per-cause fault flags (Faults) — read for "why is it faulted":

• GVn_FAULTED — aggregate (OR of all per-cause below)
• GVn_BOTH_SWITCH, GVn_NO_SWITCH, GVn_CLOSED_SWITCH, GVn_OPENED_SWITCH — switch-integrity
• GVn_FAIL_TO_OPEN, GVn_FULLY_OPEN — open-command failure modes
• GVn_FAIL_TO_CLOSE, GVn_FULLY_CLOSE — close-command failure modes
• GVn_BEAM_EXPOSURE — beam present while valve moving (interlock violation)

Permits (Display) — read for "may this valve be commanded":

• GVn_OPEN_PERMIT, GVn_CLOSE_PERMIT

Commands (Outputs + EPICS_Inputs) — write to actuate:

• GVn_OPEN_COMMAND — BLEPS-internal output command signal
• GVn_EPICS_OPEN, GVn_EPICS_CLOSE — EPICS write PVs (operator or CORA sets to 1 to command; edge-triggered, verify with _LS afterwards)

Configuration (Display):

• GVn_TYPE — valve type identifier

Recommendation for the descriptor

Keep the bare [GV1, GV2, GV3] tags in the descriptor if the model wants to be terse, but the operational readings behind each tag are two PVs: GVn_CLOSED_LS for the "isolated" state and GVn_FAULTED for the "healthy?" gate. That matches CORA's assumption cleanly — one per-valve boolean drives the Supply status, and if GVn_FAULTED fires, the per-cause fault flag(s) name the reason in the Supply transition record.

Cross-references:

• BLEPS PV inventory tables: manual/item_025.rst, sections Inputs, Faults, Outputs, Display, EPICS_Inputs.
• Related earlier answers: BLEPS-1 (cora#562) for the Supply/Asset boundary; BLEPS-2 (cora#563) for the PV naming convention (X.Y → X_Y); BLEPS-3 (cora#564) for the aggregate A_FAULT_EXISTS behaviour.