Open questions¶
What CORA needs the BMM team to confirm. This model is reverse-engineered from public open source (the NSLS2/bmm-profile-collection profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.
Priorities: Blocks-build (changes the model structure), Blocks-go-live (needed before CORA controls or observes the hardware), Nice-to-have.
Source and safety¶
| ID | Priority | Question | CORA assumes | Resolves |
|---|---|---|---|---|
| SRC-1 | Nice-to-have | The 6-BM bending-magnet source parameters (critical energy, fan). The source is confirmed a bending magnet (SR:C06), not an insertion device. |
A bending-magnet PhotonBeam Supply, identity-only. | The Source Supply settings. |
| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the front-end and photon shutters (XF:06BM-PPS{Sh:FE}, {Sh:A}) are in source. |
The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
| ENC-1 | Nice-to-have | Is the endstation a distinct hutch (6-BM-B) from the optics hutch (6-BM-A)? | Two enclosures, optics + experiment. | The Enclosure set and roles. |
Optics¶
| ID | Priority | Question | CORA assumes | Resolves |
|---|---|---|---|---|
| DCM-1 | Nice-to-have | The DCM crystal sets available (Si(111) confirmed; a Si(311) set?) and the energy range. | Si(111), range blank. | The Monochromator settings. |
| OPTIC-1 | Nice-to-have | The mirror coatings / stripes on M1 and M2 (harmonic rejection). | Two mirrors, coatings blank. | The Mirror settings. |
Sample and detectors¶
| ID | Priority | Question | CORA assumes | Resolves |
|---|---|---|---|---|
| WHEEL-1 | Blocks-go-live | The sample wheel: how many sample positions, and is batch sample-changing a CORA-modelled automation or operator-driven? Should a dedicated sample-changer Family be earned across BMM and the Diamond robots, or does the wheel stay a RotaryStage? |
A RotaryStage indexing samples; sample-changer behaviour is a Method/automation concern, not a new Family. |
The sample-wheel model and the sample-changer abstraction. |
| DET-1 | Blocks-go-live | The fluorescence detector configuration: which Xspress3 element count (1, 4, or 7) is the installed/default, and the vendor (Quantum Detectors?). Source carries all three configurations. | One EnergyDispersiveSpectrometer Asset presenting the Sensor Role; element count blank. |
The detector Model and element count. |
| DIAG-1 | Blocks-go-live | The ion chambers (I0/It/Ir) gas fill and the per-channel PV bindings. |
The quad electrometer binds the catalog FluxMonitor Family (graduated in #353); gas fill and per-channel detail unconfirmed. |
The I0/It/Ir bindings and gas fill. |
Controls and techniques¶
| ID | Priority | Question | CORA assumes | Resolves |
|---|---|---|---|---|
| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, serials, IPs. The endstation controller PV (MC:09) is in source; vendor detail is not. |
A MotionController, specifics blank. |
The MotionController Models. |
| ENERGY-1 | Blocks-build | Should CORA coin the energy_scan Capability (the catalog anticipates it as pending) now that BMM is its first real consumer, or keep XAS under characterization + energy_change until a conduct-path forces it? An XAS scan sweeps the energy axis and reads the detectors per point, distinct from the beamline_energy_change setpoint move. |
XAS mapped to existing Capabilities for now; energy_scan deferred per the design-phase discipline. |
The spectroscopy Capability decision. |
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.