What CORA needs the i06 team to confirm before the model can be trusted.
i06 was reverse-engineered from the beamline's own bluesky device layer (DiamondLightSource/dodal: the src/dodal/beamlines/i06*.py factories and the src/dodal/devices/ classes), so the control handles on the device pages are the beamline's real PVs, read from dodal rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on Model). It is a delete-on-answer queue. Priorities are Blocks-build, Blocks-go-live, and Nice-to-have.
The storage-ring state i06 reads (current, fill, machine mode).
Observe-only machine state on SR-DI-DCCT-01 / CS-CS-MSTAT-01 / SR-CS-FILL-01, a loose StorageRing.
The machine-state observation.
MONO-1
Blocks-go-live
The plane-grating monochromator gratings (line densities), the cff fixed-focus constant, and the incident-energy range and partition rule.
A soft X-ray PGM bound to GratingMonochromator, 70-2200 eV, gratings 150 / 400 / 1200 l/mm; the energy pseudo-axis decomposes to the PGM and the APPLE-II gap.
The monochromator and incident-energy Assets.
POL-2
Blocks-go-live
The IDD / IDU asymmetry: only the upstream IDU exposes the driven energy / polarization handles in dodal, while the downstream IDD stops at its controller. Should CORA expose a symmetric IDD handle?
The energy and polarization pseudo-axes are over the upstream IDU; the IDD is a sibling InsertionDevice Asset.
The polarization value domain (LH / LV / PC / NC / LA plus third-harmonic variants) and the polarization-to-phase conversion: should CORA pin the conversion as a LookupTable Calibration, or run the polarization pseudo-axis rule-less and let the live i06 controller own the kinematics?
A PseudoAxis over the APPLE-II phase rows, value domain as listed, carried rule-less by default (the controller owns the conversion).
The i06-1 diffraction-dichroism circle roles (sample theta incidence, chi / phi orientation, the DET:2THETA / DET:Y detector arm) and whether they compose an Assembly.
A Goniometer for the sample circles plus a detector arm; the Assembly(Diffractometer) is named, not built.
The diffractometer geometry; the CORA structural modelling is on Model.
DIFF-2
Nice-to-have
The reciprocal-space coordination over the diffraction-dichroism circles (the inverse-kinematics rule).
A reciprocal-space PseudoAxis over the circles, the rule deferred as on 4-ID / 8-ID / CSX.
The reciprocal-space Asset.
STAGE-1
Nice-to-have
Whether the absorption-stage theta (and the diffractometer chi / phi) warrant a Goniometer plus Assembly rather than the LinearStage placeholder.
The absorption stage bound to LinearStage as a design-phase placeholder.
The absorption-stage Family.
TEMP-1
Nice-to-have
The Lakeshore 336 cooling and heating ranges and channel assignment.
Two TemperatureController Assets presenting the Regulator Role; cooling-vs-heating a per-Asset setting; ranges pending.
The temperature-control modelling.
DET-1
Blocks-go-live
The i06-1 diffraction scattering detector and any incident-flux / drain-current (electron-yield) monitor: both are absent from dodal.
Not modelled as devices: the geometry is modelled now and the detector(s) bound later from outside dodal; no detector Family invented.
Every row above is a question about the real beamline, and any of them can be
answered by someone who knows the hardware. You do not need to edit this page
or know where it lives.
Open a short issue at
github.com/xmap/cora/issues, quote the
item ID, and write the answer in plain text. One answer is as welcome as
several. If you do not use GitHub, send the same thing to whoever shared this
page with you. If a row turns out to be a controls, network, or engineering
question, pass it to the right person or tell us who that is.
The priorities mean: Blocks-build, your answer changes the structure of the
description, so CORA cannot finalise it until you reply; Blocks-go-live, a
guess is fine for the description, but the real value is needed before CORA
controls or observes the hardware; Nice-to-have, extra detail for the record.
Once an item is confirmed we record the value and delete the row, so this page
always shows only what is still open.