CAM-1: are 2bmSP1: and 2bmbMZ1:SG: retired, powered down, or just outside arcturus's EPICS_CA_ADDR_LIST?

[xmap]

Question

Reading every PV named in the 2-BM descriptor from arcturus on 2026-08-09 (EPICS_CA_ADDR_LIST=164.54.113.168 10.54.113.24:16661), two declared prefixes returned nothing:

Prefix	Probe	Result
2bmSP1:	2bmSP1:cam1:Acquire	timed out
2bmbMZ1:SG:	(no concrete PV in descriptor)	untested, prefix only
2bmSP2:	2bmSP2:cam1:Acquire	Done

TomoScan's 2BMA substitutions also reference 2bmbSP2:, which likewise did not answer.

TIME-1 (#598) records the softGlueZynq IOC for 2bmbMZ1:SG: as running on mz-2bmb01.xray.aps.anl.gov:5064, which suggests these may be outside arcturus's search list rather than absent.

Are these prefixes:

• (a) retired,
• (b) powered down outside a run period, or
• (c) live but served by a host that arcturus does not search?

If (c), what belongs in EPICS_CA_ADDR_LIST on the acquisition host?

CORA assumes

Every prefix declared in the deployment descriptor is reachable from the acquisition host, so that a route pointing at it observes something rather than silently reading nothing.

[xmap]

Cross-reference: #636 tracks re-validating the June 2026 answer batch against current sources, and it depends on this one. If 2bmSP1: turns out to be retired rather than outside arcturus's address list, the camera identity and sensor facts recorded from #142 (DET-8) describe hardware that is not installed, and that sweep needs to cover them.

[decarlof]

Answering each prefix in turn — the short version is that none of them are retired, and the sweep would resolve after two additions to EPICS_CA_ADDR_LIST (plus a small typo in the tomoscan substitutions).

2bmSP1: — (c) live but off-host, and additionally off at scan time. This is the FLIR Oryx 5MP areaDetector IOC, one of the two cameras on top of the Optique Peter (the other is 2bmSP2: = Oryx 31MP). Both camera IOCs run on tomdet, not arcturus. Additionally: at 2-BM we conservatively leave running only the IOC of the camera currently in use, so tomdet's memory footprint stays low — the two IOCs are cycled by
operator activity. On 2026-08-09 the 2bmSP1: IOC happened to be off; starting it via ~/bin/detector_IOC_oryx_5mp.sh (which ssh's to 2bmb@tomdet and launches the areaDetector IOC) would have surfaced the PV set on the sweep. Hardware is not retired — it is currently installed and operational; see also the reply on cora#636.

2bmbMZ1:SG: — (c) live but off-host. The softGlueZynq IOC runs on the MicroZed itself (mz-2bmb01.xray.aps.anl.gov:5064, as TIME-1 / cora#598 documented) and auto-starts at boot — it is essentially always up whenever the MicroZed has power (see the 2-BM softGlue operations page, docs/source/ops/item_060.rst, "The Softglue IOC runs directly on the MicroZed module and starts automatically at boot"). It is not retire
d, not powered down at any particular time, just not reachable from an arcturus CA search unless mz-2bmb01.xray.aps.anl.gov:5064 is in the address list.

2bmbSP2: — likely a stale prefix in the tomoscan substitutions (typo, extra b). The real 2-BM Oryx 31MP prefix is 2bmSP2: (no b, as your table shows returning Done). The reference to 2bmbSP2: in TomoScan's 2BMA substitutions is almost certainly a stray extra letter — the substitutions were derived from a template that used the 2bmb... convention for other prefixes on the beamline (see 2bmbMZ1:SG:, 2bmbAERO :, 2bmbTomoScanFPGA:, etc.). The correct prefix for the Oryx 31MP IOC on tomdet is 2bmSP2: — same shape as 2bmSP1:. Worth an internal fix on the tomoscan-substitutions repo; CORA can safely treat the descriptor line as 2bmSP2: for now.

What belongs in EPICS_CA_ADDR_LIST on arcturus

To cover all IOCs the 2-BM descriptor references, arcturus needs to search:

• Localhost — for IOCs that run on arcturus itself (2bmBLEPS at 2bmBLEPS:; JenaNV200D at JenaNV200D:; energy at 2bm:Energy:; hexapod at 2bmHXP:; and others). Usually implicit but doesn't hurt to be explicit.
• tomdet (or its IP) — for the camera areaDetector IOCs (2bmSP1:, 2bmSP2:), MCTOptics (2bm:MCTOptics:), TomoScan (2bmb:TomoScan:), TomoScanStream (2bmb:TomoScanStream:), TomoScanFPGA (2bmb:TomoScanFPGA:), TomoStream (2bmb:TomoStream:).
• mz-2bmb01.xray.aps.anl.gov:5064 — for the softGlueZynq FPGA (2bmbMZ1:SG:).
• The two entries already there — 164.54.113.168 and 10.54.113.24:16661 — presumably the beamline CA gateway; keep those for any PVs that route through the gateway (PSS, ACIS, machine-state).

A single EPICS_CA_ADDR_LIST (in /home/beams/2BMB/.envrc or the equivalent shell startup for the acquisition user on arcturus) that covers everything the sweep needs would look roughly like:

EPICS_CA_ADDR_LIST="164.54.113.168 10.54.113.24:16661 tomdet.xray.aps.anl.gov mz-2bmb01.xray.aps.anl.gov:5064"

(with EPICS_CA_AUTO_ADDR_LIST=NO if you want the list to be authoritative rather than additive; leave it as YES if you want CA to also broadcast on the local subnet). The tomdet entry is what unblocks the camera sweep — but note that even with tomdet in the list, 2bmSP1: will still time out during those windows when its IOC is intentionally not running (memory-conservation policy above), so a CORA sweep that expects to
see 2bmSP1: should either be scheduled while the IOC is up or should tolerate its absence.

Summary — for the descriptor pass

• No prefix is retired.
• 2bmSP1: and 2bmbMZ1:SG: are live-but-off-host from arcturus's current address list.
• 2bmbSP2: in the tomoscan substitutions is a 2bmSP2: typo (the actual prefix your table already confirms working).
• After adding tomdet.xray.aps.anl.gov and mz-2bmb01.xray.aps.anl.gov:5064 to EPICS_CA_ADDR_LIST, the only remaining flakiness on 2bmSP1: is whether its IOC happens to be running at scan time — which is operator-driven, not infrastructural.