Experimental Physics and
Industrial Control System

From: Emmanuel Mayssat <[email protected]>

Subject: EPICSv4 and pvAccess to an IOC

Date: April 1, 2015 at 12:17:08 AM GMT+2

To: EPICS mailing list <[email protected]>

Hello all,

I am currently looking at EPICSv4.

Excellent. Pretty good isn’t it.

I am interested in better understanding pvAccess which can transfer structured data (pvData).

I understand the pvAccess can use EPICSv3 CA to access database entries in the IOC.

Yes. Specifically, you can use either:

  1. pvAccess "on the wire” to talk to an IOC; pvaAccess talks to the pvaSrv 

     plugin on the IOC, or 

  2. you can use CA on the wire through the pvAccess client side API. 

 

But how to I implement and enforce the use of the pvAccess Client Layer?

In the pvAccess API, you select the so-called “provider”, to be either pvAccess or ChannelAccess.

For an example, see the ExampleChannelGet java example [1] in “EPICS pvAccessJava”. Specifically see the lines:

        // get pvAccess client provider

        ChannelProvider channelProvider =

            ChannelProviderRegistryFactory.getChannelProviderRegistry()

                .getProvider(org.epics.pvaccess.ClientFactory.PROVIDER_NAME);

        ...  

        Channel channel = channelProvider.createChannel(

            channelName, channelRequester, ChannelProvider.PRIORITY_DEFAULT);

 

other language bindings (c++, python) etc follow the same pattern.

How do I integrate a pvAccess Server in the IOC?

So this question is assuming you’re doing method 1 above, pvAccess on the wire. In that case 

you’ll include a PVA server, named “pvaSrv” in the IOC. See the section "Adding pvAccess support to an IOC” in document Getting Started with EPICS V4 [2]. For specific examples of what a st.cmd file looks to include pvaSrv, see the st.cmd files of the test app of pvaSrv in sourceforge (e.g. see end of file st.cmd [3]).

It is my understanding that IOC programming will not chance with EPICSv4, is this correct?

That’s right. EPICS developer IOC programming doesn’t change. 

Some forward looking support for V4 is beginning to be added to the IOC. You might say the coming locksets improvement is related to V4’s requirement to properly support the future envisioned function that the value of a single PvAccess PV hosted by a classic IOC (as opposed to a V4 pvDatabase as described by Kay) can encode the values of a set of IOC records. For instance, imagine a BPM PV that encodes 5 records like X offset, X RMS, Y, Y RMS and current, all in one PV. pvaSrv can’t presently do that, it can only map a PVA PV to a single IOC PV.

Regards,
—

Emmanuel Mayssat
http://www.epicsqt.org

[1] http://epics-pvdata.sourceforge.net/docbuild/pvAccessJava/tip/documentation/pvAccessJava.html#example_source

[2] http://epics-pvdata.sourceforge.net/gettingStarted.html

[3] https://sourceforge.net/p/epics-pvdata/pvaSrv/ci/default/tree/testTop/iocBoot/testDbPv/st.cmd