Open questions¶
What CORA needs the AMX team to confirm. This model is reverse-engineered from public open source (the NSLS2/amx-profile-collection bluesky / ophyd startup files; the MX acquisition logic lives in the lsdc / mxtools libraries): the EPICS PVs are read from the startup/*.py device classes, but the goniometer / robot / detector vendor identities, the crystal cut, and physical positions are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.
Priorities: Blocks-build, Blocks-go-live, Nice-to-have.
Source and safety¶
| ID | Priority | Question | CORA assumes | Resolves |
|---|---|---|---|---|
| SRC-1 | Nice-to-have | The IVU21 undulator period, gap range, and gap-to-energy curve. The device (SR:C17-ID:G1{IVU21:1}) is in source; the parameters are not. |
An in-vacuum undulator on the 3 GeV ring, identity-only. | The InsertionDevice settings. |
| TOPO-1 | Nice-to-have | AMX (17-ID-1) shares the IVU21 undulator and the 17-ID straight with FMX (17-ID-2, which uses IVU21:2). Is the straight canted (two beams), and is one root Unit per branch the right model? | One root Unit feeding the 17-ID-1 branch (the FMX / CSX canted precedent); FMX is the sibling branch. | The sector topology and the FMX relationship. |
| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs and the front-end / photon shutter PVs (not in the profile collection; the front end is shared with FMX). | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
Optics¶
| ID | Priority | Question | CORA assumes | Resolves |
|---|---|---|---|---|
| DCM-1 | Nice-to-have | The vertical DCM crystal cut, d-spacing, and energy range. The monochromator (Mono:DCM) and its axes are in source. |
One Monochromator Asset, crystal settings blank. | The Monochromator settings. |
| KB-1 | Nice-to-have | The tandem-deflection and KB mirror coatings and calibration. The mirrors (Mir:TDM, Mir:KBH/KBV) are in source. |
The mirror internals are per-Asset settings on the existing Mirror Family. | The focusing-optic settings. |
Sample and detectors¶
| ID | Priority | Question | CORA assumes | Resolves |
|---|---|---|---|---|
| GONIO-1 | Blocks-go-live | The goniometer axis decomposition (single omega + GX / GY / GZ centring + PY / PZ pin fine) and the centre-of-rotation calibration. The stack (Gon:1) is in source. |
A Goniometer Asset (catalog Family, graduated on the i03 Smargon); per-axis decomposition to confirm. |
The goniometer model. |
| ROBOT-1 | Blocks-go-live | The EMBL sample-changing robot model, the dewar / puck layout, the exchange workflow, and the Subject custody lifecycle. The robot (EMBL) and Governor are in source. |
One Positioner-presenting Robot Asset (not a new Family); the autonomous loop is a Procedure + a Subject custody thread, gated by a Clearance. |
The robot model and the autonomous-loop modelling. |
| DET-1 | Blocks-go-live | The Eiger model and beam centre (not exposed in the profile collection), and the Mercury fluorescence detector element count and ROI map. | An Eiger (Camera, PV pending) and a Mercury (EnergyDispersiveSpectrometer); model / ROIs to confirm. |
The detector roster. |
| DIAG-1 | Nice-to-have | The beam-position channel map (the four-quadrant BPMs); the PositionMonitor Family is graduated (catalog, presenting Sensor), only the per-Asset channel map stays pending. |
Read-only beam-position (graduated catalog PositionMonitor) probes; channel map blank. |
The BeamPositionMonitor bindings. |
| CRYO-1 | Nice-to-have | The sample cryo-cooling (cold-gas cryostream), not exposed in the profile collection. | Sample cooling deferred; a TemperatureController when its PV is supplied. |
The sample-environment Assets. |
Controls and technique scope¶
| ID | Priority | Question | CORA assumes | Resolves |
|---|---|---|---|---|
| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, and IPs (the goniometer vector controller is a PowerBrick; the profile's vector PV is misconfigured to the FMX prefix). | Family bound (MotionController), specifics blank. | The MotionController Models. |
| TECH-1 | Blocks-go-live | Do the MX Methods (rotation mx_data_collection, grid_scan, sample_exchange) enter CORA's catalog, or stay pending? AMX is the third consumer (after i03, FMX). |
The three Methods reused pending; coining awaits a conduct-path (an MX integration scenario), not the sighting count (the energy_scan discipline). | The MX Method scope. |
Answering one of these¶
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.