Experimental Physics and
Industrial Control System

"Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov> · Wed, 5 Apr 2023 13:22:03 +0000

From: Michael Davidsaver <mdavidsaver at gmail.com>
> I would suggest some caution when "innovating" with custom meta-data.
> While CA enforced this by being difficult to extend, the PVA protocol
> gives the ability to transfer semi-arbitrary data structures.  However,
> there is an element of "can" vs. "should" to consider.

Right. With PV Access we can now create new data types.
The protocol supports it, and you can actually do that in several ways.
Write some C++, Java or python code to create & publish a custom structure, or use the 'group' annotations on records in the IOC.

But as Michael suggests, being able to doesn't mean that you should or have to do that.
When you create a custom structure, generic clients have no idea how to handle them.

SNS uses a custom structure for neutron data (https://controlssoftware.sns.ornl.gov/training/2022_USPAS/Presentations/24%20PV%20Access.pdf) The server side is written in C++, and so is the client side. In that case, PVAccess was used because it's a fast protocol (better than 'JSON' via http...), and you can use 'pvmonitor' or 'probe' to debug (Is the server running? Is it sending updates? Does the data look reasonable?) To a limited extend, you can use a generic client like CS-Studio probe or display builder to look at "pva://that_custom_pv/substructure/value", but no generic client will understand the full "pva://that_custom_pv". Yes, you could compile your own version of CS-Studio that includes an "SNS Neutron Data Display" which understands this structure, but the idea is not to design custom data for each device and then compile/deploy updates to each client whenever you add a new gadget to the machine.

The 'circle.db' from 'makeBaseApp.pl -t example' shows how data from records is combined into a custom structure. Generic displays will still show information from the underlying records as they've done for the last 30 years. The combined custom structure offers some advantage like atomic updates for custom clients like a python client, but it doesn't replace the basic "normative types" or channel access data structures with value/time/status/units for 99% of the EPICS tools.

A counterexample: You might consider creating one large "Accelerator" data type that consists of an array of "Cavities" which each have a "Vacuum" reading, an "RF Amplitude Setpoint" etc., then assume that "pva://Accelerator/Cavities[47]/Vacuum" gets you one vacuum reading, while just "pva://Accelerator" can be added to the archiver, and the protocol will efficiently only transfer changes over the network.
It's not meant to be used that way. Such a structure would be way too large and inefficient.

-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System