Detailed PVs

[ax3l]

Instead of just using a generic MetaP attribute (#48), we need add a very well defined PV property for control system identification.

[DavidSagan]

I agree. PVs should have a separate (and well defined) structure separate from MetaP.

[zhanghe9704]

I would like to provide a specific case. At JLab, we are working on our demo problem on RF cavity radiation. For this problem, we found the need to include at least the following information for each element in PALS format.

1. EPICSName - the name of the element in EPICS
2. Data channel names - the name of the data channel of time series data. These are often referred to as "PV"s by my colleagues.
3. S coordinate - This is redundant because it can be calculated from the lattice. However, it could be convenient for data scientists because they may not use the whole lattice but filter out some elements they need. However, they still want to know the relative location of the elements.

Any suggestions on how we should proceed? Thanks.

[DavidSagan]

The s-coordinate will be provided by the PALS translator. In terms of EPICS, there will need to be a PR to establish a standard. If you want to work on this, there could be a discussion as to how to structure things.

[zhanghe9704]

I'm not sure if I'm the right person for this since I don't have much experience with EPICS. However, if no one more experienced is available right now, I can start working on a prototype. Is there any guidance for beginners? I'd also like to have a discussion about it.

[DavidSagan]

Personally I don't know of anyone working on this. @jlvay Perhaps this should be discussed at a PALS meeting?

[ax3l]

@zhanghe9704 commented today:
We need attributes for:

• control system software name
• software version
• connection URI (e.g, IP address/port)
• etc.

@roussel-ryan will add some example/work we can refer to at SLAC

[roussel-ryan]

See examples here from slac-tools: https://github.com/slaclab/lcls-tools/blob/main/lcls_tools/common/devices/yaml/GUN.yaml