Experimental Physics and
Industrial Control System

Hi Dave and all,

 

Just to add my perspective to this issue.

I fully agree that even as a pure replacement of CA, PVA has a lot of value. Using PVA would be worthwhile even if that was the only thing. Andrew and Kay already outlined the benefits.

 

But the benefits do not, and certainly do not need to end there. We at ESS are starting to make a lot of use of the structured data facilities.

 

For now, the main way to take advantage of them is to use the “group PV” capability. It may seem limited at the first look, but when one dives a bit deeper, they offer quite a lot:

 

• The well-proven record types and their functionality can be used as before. They can be templated, initialized, auto-saved, etc. This has enormous value. No need to re-invent the wheel, and re-debug things that work.
• You can achieve “atomic” processing of several records by using the group feature. Before PVA, to achieve this one needed to resort to complicated trickery, if it was possible at all. Or bypass the record layer, which led to another set of problems.
• Groups can freely be composed of smaller units, that let you to phase your development without a) having to re-implement those small units every time and b) being constrained to fixed structures.
• Adhering to normative types, you get a quite good level of interoperability. Normative types are not perfect for all cases but can express most of the things that are needed. That said, I think there is still need for refinement in the normative types and their definition.
• There are some smaller but important low-hanging fruits that we at ESS are starting to take advantage of. One example is the User Tag/UTAG that can be used to augment the “classic” timestamp.

 

I have heard complaints that the group definition syntax is complicated. There may be possibilities to simplify or clarify it, but in the end there is no free lunch.

 

Just as a remark, the distinction between a (group) PV and a record does not always seem to be clear. I simplify the concept in my head by thinking that the DBR types of CA and NTypes in PVA are both pre-defined queries to the EPICS database. The difference between them is that with CA, you can only query one database record at a time, with PVA and groups you can extend the query to multiple records.  

 

Now, nothing of the above excludes the possibility of implementing record types that have “native” normative type structures. With those, a number of entirely new capabilities would become available. There have been activities in this direction, but as this requires substantial groundwork, it has been slow to progress.  They would in this case still be records that are defined in the dbd files, can use templating, initialization, etc.

 

Then there is of course the possibility to provide structured data without a database, pure custom programming. I personally think that this is of limited use, obscures the system by hiding logic behind custom implementations and reduces generic applicability. Thus I recommend against it, and have not yet seen a case where the equivalent (or better) could not have been achieved with PV groups.

 

In my opinion, the record types and providing record instances is still as relevant as it has always been, and for me they are the most powerful features of EPICS.

 

Best regards,

 

Timo

 

Hi Dave,

 

Yes, PVXS is evolution, not revolution.

 

That's also why our version numbers jumped from 3.16.x to 7.x back in 2017 — EPICS 7 is the combination of the IOC developments up to Base 3.16.2 with the new PVA protocol from what was then being called EPICS V4. We realized once V4 was becoming functional that to support our existing users (who were also the employers of most of the core EPICS developers) we had to provide a path for upgrading existing IOCs and control systems, without forcing them to be significantly rewritten — none of the US DOE sites would have been able to do that. Some work had been done to develop an EPICS V4 IOC (in Java), but it wasn't designed to be backwards-compatible at all and there was no way it could have ever run databases from an existing V3 IOC.

 

We are thus being careful to implement changes by evolution instead of revolution, and PVXS was how Michael Davidsaver chose to fix some of the major issues with the architecture and APIs implemented in pvDataCPP and pvAccessCPP. We haven't decided how and when it might be integrated and included in official EPICS releases, but I'm sure it will happen sometime. Users who rely on on the pvDataCPP and derived APIs will continue to be able to build against and use those libraries, but there isn't much development being done on them now.

 

Replacing the GNU make-based build system would be a revolution since there are so many existing IOCs and control systems based on it. We have considered a proposal to permit builds using meson, and if enough members of the EPICS community express interest and offer to provide long-term effort to maintain an alternative build system we could include one, but removing the existing build system would be hard to do given all the EPICS installations around the world that have thousands of applications, many with customized Makefiles and local build rules. Maybe AI…

 

- Andrew