Description, motivation and use case
The HZB controls group has recently decided to move the orbit object for BESSY II (and eventually MLS) to use structured data. The orbit object for BESSY II now returns a table with columns for BPM name, x, y etc. This new PV also uses PV access instead of channel access like the rest of the PVs.
Documentation for how the type looks like is here: https://docs.epics-controls.org/en/latest/pv-access/Normative-Types-Specification.html?utm_source=chatgpt.com#nttable
This new PV has been added to the newer version of the BESSY II twin. It can be tested using these steps:
- Start the twin.
apptainer run oras://registry.hzdr.de/digital-twins-for-accelerators/containers/pyat-softioc-digital-twin:v0-5-3.2898073
- Start the EPICS tools container in a separate terminal.
apptainer run oras://registry.hzdr.de/digital-twins-for-accelerators/epics-tools:latest
The pvlist now returns two GUIDs, one for the channel access PVs and one for the PV access PVs.
epics tools ~ > pvlist
GUID 0x6B6D9B722AE3F7546DB05A36 version 2: tcp@[ 192.168.0.151:5075 ]
GUID 0xFD3792D39C614D57C3D821B0 version 2: tcp@[ 192.168.0.151:32867 ]
The output for the channel access looks like before (this PV is kept for now for legacy reasons but will eventually go away):
epics tools ~ > pvlist 0xFD3792D39C614D57C3D821B0 | grep ORBITCC
a3744:ORBITCC:count
a3744:ORBITCC:rdBpmNames
a3744:ORBITCC:rdButtons
a3744:ORBITCC:rdPos
It can be read with caget.
And for PV access:
epics tools ~ > pvlist 0x6B6D9B722AE3F7546DB05A36 | grep ORBITCC
a3744:ORBITCC:rdBpm
It can be read with pvget. The output will look like:
epics tools ~ > pvget a3744:ORBITCC:rdBpm
a3744:ORBITCC:rdBpm 2026-06-04 13:05:04.164
A B BPM C D X Y
3.12154e-06 2.95725e-06 BPMZ5D1R 2.79296e-06 2.62867e-06 3.28584e-06 0
2.08537e-06 1.97561e-06 BPMZ6D1R 1.86586e-06 1.7561e-06 2.19513e-06 0
1.0642e-05 1.00819e-05 BPMZ7D1R 9.52178e-06 8.96167e-06 1.12021e-05 0
1.66822e-05 1.58042e-05 BPMZ1T1R 1.49262e-05 1.40482e-05 1.75602e-05 0
9.47385e-06 8.97523e-06 BPMZ2T1R 8.4766e-06 7.97798e-06 9.97248e-06 0
Proposed solution
The option to configure the BPMs using indices in array should be kept since this will be required also in the future. An additional option needs to be added that allows to map columns in the table to the correct BPM.
Description, motivation and use case
The HZB controls group has recently decided to move the orbit object for BESSY II (and eventually MLS) to use structured data. The orbit object for BESSY II now returns a table with columns for BPM name, x, y etc. This new PV also uses PV access instead of channel access like the rest of the PVs.
Documentation for how the type looks like is here: https://docs.epics-controls.org/en/latest/pv-access/Normative-Types-Specification.html?utm_source=chatgpt.com#nttable
This new PV has been added to the newer version of the BESSY II twin. It can be tested using these steps:
The pvlist now returns two GUIDs, one for the channel access PVs and one for the PV access PVs.
The output for the channel access looks like before (this PV is kept for now for legacy reasons but will eventually go away):
It can be read with
caget.And for PV access:
It can be read with
pvget. The output will look like:Proposed solution
The option to configure the BPMs using indices in array should be kept since this will be required also in the future. An additional option needs to be added that allows to map columns in the table to the correct BPM.