Re: PVXS IOC Philosophy

["Cobb, Tom \(DLSLtd,RAL,LSCI\) via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Dave,

I'm going to respond to this from the perspective of runtime introspectable Devices.

Our current stack is based on an EPICS V3 IOC, with EPICS support modules containing C and C++ code compiled in, then static databases instantiated based on the prior knowledge of what the device is capable of doing. We are then adding PVXS to the IOC (via QSRV2) so we serve the records over PVA as well as CA.

However we have some devices where we don't know at build time what features it has, as they are only known at runtime, like in the case of PandABox. For this we use pythonSoftIOC to construct a V3 IOC with python device support, which introspects the device at runtime and makes records based on what the device says it can do. We also add PVXS to that IOC so it serves records over PVA as well as CA. We also plan to try this approach for GigE cameras, constructing the ADAravis database by talking to the camera at runtime rather than generating it at build time.

This approach means we get a V3 record for every field that the device supports, including things like .DESC​, .EGU​, .HIHI​ etc.

Having said that, we don't actually ​need any of those record fields: only the record PV appears on the UI, not any of its fields. We just use them to insert metadata into the resulting structure, so we could move to using PVXS (via p4p for the python support) to serve just the PV for the record (with its metadata), and not any of its fields.

We would like to leave this decision open in the future, so we are writing FastCS, a control system agnostic framework for building Device support in Python IOCs, with pluggable backends for pythonSoftIOC, PVXS, or PyTango. This last one is important for the PandA collaboration so we can expose the same functionality to facilities that run Tango as those that run EPICS.

Thanks,

Tom

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Johnson, Andrew N. via Tech-talk <tech-talk at aps.anl.gov>
Sent: 20 March 2024 18:38
To: Dave Bracey <dbracey at fnal.gov>; Kasemir, Kay <kasemirk at ornl.gov>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: PVXS IOC Philosophy

 

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

 

 

On 3/20/24, 12:43 PM, "Dave Bracey" <dbracey at fnal.gov> wrote:

 

First, thank you everyone for the discussion, it is great to get more context filled in as I learn this stuff.

 

Andrew, to answer your question, I’m primarily after using the tech with the best future, so I was interested in PVXS just from that perspective.  CA is not an issue.

 

I think my confusion stems mostly from reading the PVXS doc at https://mdavidsaver.github.io/pvxs/ and noticing that it doesn’t mention DB-style “records” anywhere, but it does give examples of building PV’s programmatically at run-time.  This caused me to wonder “is this the new way?”

 

But from  you guys have been saying here, am I right to think that PVXS is mainly a replacement implementation of pvAccessCPP, etc. and is not intended to change things for the basic IOC developer? 

 

From: Johnson, Andrew N. <anj at anl.gov>
Date: Wednesday, March 20, 2024 at 12:30 PM
To: Dave Bracey <dbracey at fnal.gov>, Kasemir, Kay <kasemirk at ornl.gov>, tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: PVXS IOC Philosophy

[EXTERNAL] – This message is from an external sender

Hi Dave,

 

When you say PVXS, are you really asking about building IOCs that provide both a Channel Access and PV Access server, or about using the specific PVXS implementation instead of the original pvAccessCPP?

 

You don't need PVXS to create IOCs that can talk the PVAccess protocol. PVXS started as a reimplementation of the original C++ client and server code for the PVA protocol but using a better internal architecture and written in modern C++. It can communicate over IPv6 now, and future releases will be able to use TLS for much improved security, but those won't change the underlying IOC code significantly.

 

- Andrew

 

On 3/20/24, 12:06 PM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:

 

> I’d say the prevalent scenarios would still be IOCs with records, and PVAccess is then

> used just like Channel Access. That’s why we have normative types which mostly mirror

> the DBR_.. types, and clients like CS-Studio that can fairly transparently switch between

> the two protocols.

 

I guess I’m unsure what the value of PVXS would be in a scenario like that?  If you are starting from a normal EPICS IOC project, and adding PVXS, what is PVXS doing for you?  You are still defining your PV’s in terms of records in DB files, etc.

 

I can see that if you are building an IOC for an embedded architecture, the EPICS build system adds value in being able to handle the different toolchains and build products, etc.

 

However, at the moment I’m looking at making a soft-IOC (i.e. on intel/amd64 linux), and I’m seeing the opportunity to use a simpler (and contemporary) build system and construct PV’s at run-time, rather than use DBD/DB which need to be consumed at build.

 

I’m wondering if this is a compelling idea at all, or a poor idea?

 

From: Kasemir, Kay <kasemirk at ornl.gov>
Date: Wednesday, March 20, 2024 at 11:43 AM
To: Dave Bracey <dbracey at fnal.gov>, tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: PVXS IOC Philosophy

[EXTERNAL] – This message is from an external sender

I’d say the prevalent scenarios would still be IOCs with records, and PVAccess is then used just like Channel Access. That’s why we have normative types which mostly mirror the DBR_.. types, and clients like CS-Studio that can fairly transparently switch between the two protocols.

 

With PVAccess you do now have the option to use new types. It allows you to transfer site-specific data over the same protocol, but you can’t expect generic widgets to fully understand your data. That mostly means you need to create both the server and the client, which you can do in python etc.

 

The new ‘group’ feature does allow you to create custom types by on combining data from records, but for the client side you’re then again on the hook to create for example a python script to understand that custom data.

 

So bottom line the goal here should not be that every piece of information now needs to be placed in a newly developed data type with its own custom server and client. On the contrary, the existing record types, the normative types to read/write them, and generic clients like display managers are meant to fill most of your needs, as was the case with EPICS for the last 30 years.

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Dave Bracey via Tech-talk <tech-talk at aps.anl.gov>
Date: Wednesday, March 20, 2024 at 12:30 PM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: [EXTERNAL] PVXS IOC Philosophy

Going forward, is the philosophy of PVXS to create PV’s programmatically, per the examples (i.e. https://mdavidsaver.github.io/pvxs/example.html#mailbox-server) ?

 

Or, is the idea of creating PV’s by providing record definitions and instances via DBD / DB files still intended to be relevant?

 

One can create a hybrid IOC (https://mdavidsaver.github.io/pvxs/ioc.html) and still take in DBD/DB files, but this doesn’t seem to really involve PVXS, at least from the developer’s perspective (other than the fact that QSRV2 makes it work).

 

As always, I may be completely wrong about any of that, so feel free to let me know.

 

Dave Bracey – Fermilab AD Instrumentation