Skip to content

TEST-1: 2-BM tomoscan Testing PV exposes real-vs-test scan-provenance; CORA should read 2bmb:TomoScan:Testing at scan-start and record real=false in the receipt when Yes #657

Description

@decarlof

Summary

The 2-BM tomoscan client exposes an EPICS PV that captures whether the current scan is a real acquisition or an operator-run test. This is exactly the source-of-truth CORA needs for the "real, not simulated" claim announced in the 2026-08-13 verifiable-receipts briefing.

  • PV name: 2bmb:TomoScan:Testing
  • Type: DBR_ENUM (Yes / No)
  • Access: read + write, CA-reachable
  • Host: 169.254.100.68:37591 (the tomoscan IOC on tomdet)
  • Live value at time of writing (2026-08-13): Yes

Semantics

When 2bmb:TomoScan:Testing = Yes:

  • Tomoscan ignores the "we do not have beam" state (i.e. bypasses the shutter / beam-ready / hutch-searched preconditions).
  • Shutters remain disabled at the safety layer (this is the physical state during a real machine shutdown like the current one), but tomoscan does not refuse to run because of that.
  • Hutch-search state is not checked.
  • The scan otherwise runs the full trigger-and-acquire pipeline (tomdet acquires frames, the HDF5 plugin writes a file, tomoscan post-processes) — it is a real-file, real-metadata run, just without any real X-ray beam.

When 2bmb:TomoScan:Testing = No:

  • Tomoscan enforces the normal beam / shutter / hutch preconditions.
  • The scan represents a real X-ray acquisition.

Why CORA should read this PV at scan-start

Yesterday's briefing established that the receipt now declares real-vs-simulated and seals that declaration with the rest of the payload. The declaration needs a ground truth. 2bmb:TomoScan:Testing is that ground truth for 2-BM. Reading it once at scan-start (via a plain CA caget)
and stamping the value into the receipt is a one-line addition that closes the loop end-to-end.

Recommendation:

  • Every 2-BM scan begin event that CORA ingests: issue a single CA read on 2bmb:TomoScan:Testing.
  • If Yes: set real = false in the receipt (or the equivalent field in the receipt schema); optionally add a test_mode_source = "2bmb:TomoScan:Testing" provenance field so a future reader can see which PV was consulted.
  • If No: set real = true.
  • If CA read fails or times out: treat as unknown; the receipt should say so explicitly rather than defaulting to either value. This is the same "record what you observed, do not fabricate" pattern CORA already applies to timestamps.

The PV is read-only from CORA's perspective (CORA has actuation set to INERT), so this is a safe addition — no chance of CORA accidentally toggling the flag itself.

Current operational context

Today (2026-08-13) the beamline is running with Testing = Yes for a series of test tomoscans. The APS is in the current shutdown window (started 2026-08-05 08:00 CDT) so there is no beam available; the operator is exercising the tomoscan + client + IOC + file-writer path end-to-end w
ithout beam so that the pilot receipts flowing to CORA include real-file, real-metadata test-mode scans in the audit trail with the correct real=false provenance. This is the operational context CORA's receipts should reflect.

Related

  • Yesterday's briefing (2026-08-13) — verifiable-receipts capability; the "real, not simulated" claim is the field this PV should populate.
  • DATA-8 / cora#655 — the closely-analogous scan-metadata-provenance ticket about /process/acquisition/start_date. Same "ground-truth PV -> receipt field" pattern; different receipt field.
  • MODE-1 / #260 and siblings — the Mono / Pink beam-mode taxonomy. Testing is orthogonal to Mono/Pink: both are attributes of the scan-run state, but Mono/Pink is about optics configuration and Testing is about whether the shot has real
    photons in the beam path.
  • The 2bmb:TomoScan:Testing PV lives in the tomoscan IOC substitution file at /home/beams/2BMB/epics/synApps/support/tomoscan/; it is a boolean stringout / bo record in the tomoscan .substitutions.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions