Re: [EXTERNAL] PvaPy pvaccess

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

Hi,

In this particular case the problem has nothing to do with CA provider, but simply that CA constant was used without being imported (like Simon already suggested). In other words, the statement

ourPVchannel = pvaccess.Channel('int01',pvaccess.CA)

would have worked just fine.

Also, as far as the statement regarding "running into specific providerType=CA issue", I would like to note that pvapy is actively maintained and developed, and if there are any real issues encountered with either CA or PVA providers, please do not hesitate to let me know or open an issue on github.

Thanks,

Sinisa

--

Siniša Veseli

Scientific Software Engineering & Data Management

Advanced Photon Source

Argonne National Laboratory

sveseli at anl.gov

(630)252-9182

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Kasemir, Kay via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, May 10, 2023 8:17 AM
To: S Banerian <banerian at uw.edu>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: [EXTERNAL] PvaPy pvaccess

 

Hi:

 

> As part of that, we are trying out pvaccess PvaPy as an update to the pyepics that is currently used.

PvaPy is not necessarily an update to pyepics. See https://epics.anl.gov/extensions/index.php for all the python libraries.

 

pyepics was, is and will remain a channel access library for python.

But there’s also caproto, cothread, .. depending on your preferences. Yes, a bit confusing which one to choose. If you were happy with pyepics, nothing wrong with continuing to use that for channel access.

 

With EPICS 7, your IOCs can not only use channel access but also pvaccess.

For using pvaccess from python, you currently have two options: PvaPy or p4p.

PvaPy is based on the original C++ implementation consisting of pvAccessCPP, pvDataCPP and some more.

P4p is based on the new C++ implementation, PVXS.

Which one to pick there? PVXS was created to overcome limitations of the original implementation. One of them being that it tries to have the same API for C++ and Java, which is troublesome because those languages have fundamentally different approaches. The other is that pvAccessCPP, pvDataCPP etc. also try to support channel access, which really is a different protocol, and that’s where you run into the specific providerType=CA issue. Finally, PVXS sees active development like support for IPv6, while pvAccessCPP, pvDataCPP, .. are just barely maintained.

 

So one suggestion for python would be to keep using pyepics for channel access, and if you want to start accessing some of the data via pvaccess, use p4p.

 

-Kay

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of S Banerian via Tech-talk <tech-talk at aps.anl.gov>
Date: Wednesday, May 10, 2023 at 4:48 AM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: [EXTERNAL] PvaPy pvaccess

I've set to work on upgrading some of our local EPICS infrastructure, and have (finally) installed Epics 7 on a couple of machines.

As part of that, we are trying out pvaccess PvaPy as an update to the pyepics that is currently used.

On a test system, i've been following the documentation [1,2] for PvaPy to monitor some pv's we track.

alas, we do not get the desired behaviour for monitoring CA   PVs.


pvaChannel = Channel('enum01')
pvaChanne.isConnected()
pvaChannel.subscribe('echo', lambda x: print(f'{x}'))
pvaChannel.startMonitor()

(no errors encountered)

but when  non-default is tried:

ourPVchannel = pvaccess.Channel('int01',CA)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'CA' is not defined

pvaccess.Channel('int01',providerType=CA)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'CA' is not defined


suggestions as to what I can try next?

[1] https://urldefense.us/v2/url?u=https-3A__github.com_epics-2Dbase_pvaPy&d=DwIBAg&c=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc&r=8RMagXS5oBauLyLs1HfVUTdnjjuRYthZ97c5pPc4pBQ&m=Hrm7LtzAEx4URk57OzhuRthN6XhHIA3dZ_Z2ypVCLNcC9tyVbMcMcM0goY0QZSjs&s=DOiea-iMuYz_PCSXY6elXvUlkzULO1TwenA8fU52zYI&e=
[2] https://urldefense.us/v2/url?u=https-3A__epics.anl.gov_extensions_pvaPy_production_pvaccess.html-23channel&d=DwIBAg&c=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc&r=8RMagXS5oBauLyLs1HfVUTdnjjuRYthZ97c5pPc4pBQ&m=Hrm7LtzAEx4URk57OzhuRthN6XhHIA3dZ_Z2ypVCLNcC9tyVbMcMcM0goY0QZSjs&s=DzeqDe8r0h0FWh4yQxYo8ymW7nnJE5SWRvMICVQiEs4&e=


s banerian
UW Clinical Cyclotron