Re: Pva-ify questions

["Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov>]

Hi!

If you want to move from CA to PVA, it's typically straight forward to add a PVA server to your IOCs.

You may, however, have older VME/VxWorks IOCs, or other CA servers based on PCASpy, LabVIEW, site-specific C/C++ code that can't be updated to include a PVA server.

pva-i-fy (https://github.com/ControlSystemStudio/pvaify) is meant to help with that. It's similar to a CA or PVA gateway, see "PVA Gateway" on https://controlssoftware.sns.ornl.gov/training/2026_USPAS

It has a PVA server side and a CA client side. Your PVA clients will talk to the PVA server side, and the CA client side will then call out to those older CA servers that can't be updated to directly support PVA, yet.

It's meant as an intermediate step on your path to make all control system data available via PVA. Eventually, those CA-only IOCs or servers should be updated to include PVA and eliminate the need for the pva-i-fy gateway.

 

> Does the pva-ify server appear as an IOC in its own right, serving PVs?

It's not an IOC. It's a PVA server and CA client. Check "CA vs Records vs CAS" on https://controlssoftware.sns.ornl.gov/training/2026_USPAS for the difference between IOCs (records and fields) vs. CA/PVA servers (channels and properties).

> Or does it invisibly transmute the packets,

It's a CA client, reading DBR_... data from the older CA servers, then providing that data via its PCA server side as normative types.

> leaving the originator’s user credentials and host information intact?

It's just like the CA and PVA gateways. What your CA server (IOC) will see is a connection from the user ID that's running the gateway or pva-i-fy, originating from the host where the gateway or pva-i-fy is running. The CA server (IOC) will NOT see the original client user ID and host. Gateways also act as concentrators. Multiple clients can access the same PVs via the gateway. The IOC on the other end only sees one connection, one client, namely the gateway. Bottom line: On the IOC, you won't see "Fred" on his office PC as a client, you see "gateway user" at the "gateway host". On the IOC, you can't control access for "Fred" that way. For that reason, gateways tend to be read-only, or on a private network where write access is generally permitted.

> The README mentions bridging between two networks, with CA on one side and PVA on the other.  Is having two distinct networks a requirement?

You need to configure where the PVA server side listens for clients' search requests, and where the CA client side searches for those requested channels. Server and client sides may be on the same subnet or on different networks.

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of David Bracey via Tech-talk <tech-talk at aps.anl.gov>

We are interested in using pva-ify to bring some CA iocs into our PVA-only EPICS deployment.

Some questions, from having only read the README and attempted the demo:

1.  Does the pva-ify server appear as an IOC in its own right, serving PVs?  Or does it invisibly transmute the packets, leaving the originator’s user credentials and host information intact?
2.  Is there any “loss of fidelity” translating CA to PVA, or vice versa?  Obviously CA does not do normative types, so something has to happen there.
3. The README mentions bridging between two networks, with CA on one side and PVA on the other.  Is having two distinct networks a requirement?  The demo simply has one run a CA softIoc, and then look for PVA versions of the PVs.

I confess I have not been successful with the demo yet, but I have only just set it up and done an hour’s tinkering.  I would like to get a little deeper into it before asking for further help.