Handle LabView-EPICS AIs, DIOs, State Variables

[padraic-shafer]

Currently only motor record PVs are exported from LabView for this package to store via happi.

Controls systems will also need to know which AIs, DIOs, and State Variables are active in the LabView configuration.

[padraic-shafer]

Several steps will be needed to implement this.

1. LabView code will need to export the names of PVs associated with active AI channels, DIO channels, and State Variables.
2. labview2happi needs to store these PVs (or their equivalent ophyd devices) in a meaningful format for happi
3. Some adapter would be needed for happi to construct useful ophyd devices from these database entries

[padraic-shafer]

1. LabView code will need to export the names of PVs associated with active AI channels, DIO channels, and State Variables.

These could be output locally from LabView in a separate text file for each grouping (Motors, AIs, DIOs, SVs), or with all of them in a single file with some delimiter (Header rows) or JSON structure for the 4 groupings.

@LeeYangLBLBCS What makes sense for your code updates in LabView?

[padraic-shafer]

2. labview2happi needs to store these PVs (or their equivalent ophyd devices) in a meaningful format for happi

Here's where we'll need to brainstorm a bit. It could be as simple as storing the PV names (or prefixes) for the applicable PVs in each grouping (Motors, AIs, DIOs, SVs). This is probably the right first approach, but I suspect we will want to revisit this later to define structured ophyd devices that should be stored.

I recommend we store each grouping in a separate collection within a common db. This will help with readily identifying or targeting the device type. [2023-02-24: Overruled by this comment. :)]

@paglans @taxe10 @Wiebke @dylanmcreynolds

[padraic-shafer]

3. Some adapter would be needed for happi to construct useful ophyd devices from these database entries

This is where some jointly defined structured ophyd devices will be most useful.

[paglans]

In a chat with Dylan: Limiting the number of collections as much as possible is preferred. There is already a field in the record for each device indicating what it is. Searching and indexing across collections is quite tricky. Dylan recommends staying with one collection.

[padraic-shafer]

Some background...

Motors

Ophyd provides built-in support for some EPICS devices. Of these, EpicsMotor maps directly to BCS Motors.

AI channels

BCS Analog Input channels are converted by the BCS-EPICS bridge into read-only PVs that end with ai-AI. These most readily map onto EpicsSignalRO objects in ophyd.

State Variables

BCS State Variables are generally read/write (or sometimes read-only) variables, converted into PVs ending with -SV. These probably map most readily onto EpicsSignal or EpicsSignalRO objects in ophyd. The read/write variants should be grouped as pairs.

suffix/field	type	mode
ai-SV	Analog/float value	input/read
ao-SV	Analog/float value	output/write
bi-SV	Binary/boolean value	input/read
bo-SV	Binary/boolean value	output/write
longin-SV	Long int value	input/read
longout-SV	Long int value	output/write
stringin-SV	String value	input/read
stringout-SV	String value	output/write

DIO channels

BCS Digital Input/Output channels are either read/write or read-only boolean (or tri-state?) values, converted into PVs ending with bo-DIO (write) or bi-DIO (read). These probably map most readily onto EpicsSignal or EpicsSignalRO objects in ophyd. The read/write variants should be grouped as pairs.

---

Additional reference

• Signals
• Custom devices

[paglans]

1. If the labview code can be extended to treat AI's, DIO's, and SV's the same way as the motors, it looks to me like (2.) we can deal with the different types of devices in the python script. The get_pvIOC_PVs.vi already outputs all(?) the names. sendToMongoDB.vi needs to be extended to iterate over AI's, DIO's, and SV's in a similar way as for the motors. This will output all the device names as LabView BCS knows them. If we add a parameter for device type ("MO", "ai-AI", various -SV"'s) to the input argument list of the write_pv_to_mongo.py script, it'll be quite straightforward to map the different labview names to proper ophyd devices. The sendToMongDB.vi will have to call the python script once for each device type.

[ronpandolfi]

You may want to reflect the EPICS Record classes for comparable LabVIEW records, as has been done with motor records. For example, there is an AI Record class. This will enable additional features for some clients (pyDM/Typhos/Xi-CAM, etc.) by providing a more familiar EPICS defined device structure. The EPICS AI Record includes a variety of meaningful adjacent fields, such as engineering units and alarm limits.

[ronpandolfi]

A potentially helpful reference is the EPICS Record Reference Manual. Chapter 4 is AI records.

For querying happi with a filter (i.e. find all AIs from labview), it could be helpful to agree on common language for various supplementary fields. The LCLSItem entry class enforces certain fields that are standard for LCLS. We could consider designing our own entry schema.

Also, I've been using a source field with value labview for devices served by the bridge IOC.

[padraic-shafer]

A potentially helpful reference is the EPICS Record Reference Manual. Chapter 4 is AI records.

That is a great idea. I think these AI record fields are not currently created by the LV-Epics bridge, but hopefully I'm wrong about that. @ronpandolfi @LeeYangLBLBCS Are you currently getting this functionality from the bridge?

[padraic-shafer]

For querying happi with a filter (i.e. find all AIs from labview), it could be helpful to agree on common language for various supplementary fields. The LCLSItem entry class enforces certain fields that are standard for LCLS. We could consider designing our own entry schema.

Yes, this would be a good thing to do together. I think most of the LCLS fields don't apply to our conventions, so we'll need to put a bit of thought into what is most useful for our use cases.

Also, I've been using a source field with value labview for devices served by the bridge IOC.

Here are some examples to get us started...

happi item field	description	example	notes
source	origin of device info	"labview"	Perhaps we should augment / replace this with server name
beamline	beamline associated with the device	"7.0.1.1"; "4.0.2"	This one is not as simple as it seems (1)
description	useful description about the physical device	"Angle of PGM grating"
groups	logical groups that the device belongs to	["beamline", "mono", "mirror"]; ["amplifier", "endstation_1"]; ["magnet", "power_supply", "endstation_2", "hidden"]	Devices can belong to multiple groups; controls clients can use these to organize related motors or other devices
Others?

---

Notes

(1): I think there might be potentially 3 different beamline IDs depending on the use case:

1. Beamline ID used in ESAF
2. Beamline ID used in "Beamline Roles"
3. Common usage (either the number or the name)

For some beamlines/branchlines, all 3 could be the same, but not for others. I think we could include a grouping (dictionary) that provides all 3 in the metadata, so that downstream apps could knowingly select the one they need. Thoughts?

Example:

"beamline": {
    "from_esaf": "7.0.2",
    "from_roles": "7.0.2.1",
    "public": "MAESTRO",
}

[padraic-shafer]

Does anybody use these fields?

https://github.com/als-computing/labview2happi/blob/c430928f6e1a7436c8378101cc08a9f33e3a0301/write_pv_to_mongo.py#L63-L64

If not, we should consider removing them.

[dylanmcreynolds]

@pshafer-als is Beamline ID used in "Beamline Roles" roles from the 4D API?

[padraic-shafer]

@pshafer-als is Beamline ID used in "Beamline Roles" roles from the 4D API?

Yes, That’s the version corresponding to the “from_roles” field above.

[padraic-shafer]

@ronpandolfi It would be great to see how you are doing this at COSMIC. Is there a repository you could share?