RE: New to EPICS - v4 questions

[Stainer Tom via Tech-talk <tech-talk at aps.anl.gov>]

Thanks Kay and Mark!

 

I appreciate the extensive response, very helpful. It is clear that I cannot go full PVA yet.

 

I must say that the API for PVXS is somewhat cleaner and easier to use, but the documentation and examples for pvAccess + pvDatabase makes it easier to get started with.

 

With respect to the “vision” of EPICS and the longer term plan (if there is such a thing), what are the intentions with regard to support and endorsement?

- For example, is Phoebus going to fully superseed CSS?

- What functionality is missing, if any, from Phoebus which is currently supported by CSS?

- Is there any intention to deprecate pvAccess et al in favour of PVXS or will the two coexist?

 

Besides epics-base and the CA vs PVA debate, the plethora of modules available in EPICS is also somewhat daunting to a new user. Mark you touched upon areaDetector, which indeed looks useful, but how does one get started with the modules? Do you typically adopt them on a need by need basis? Specifically is there any documentation and/or examples on how these modules all relate to each other and how they are generally used in production?

 

Maybe the some of my questions are too broad but it would be nice to know what people are using out in the wild…

 

Kind regards,

Tom

 

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Friday, March 5, 2021 6:33 PM
To: 'Kasemir, Kay' <kasemirk at ornl.gov>; Stainer Tom <Tom.Stainer at sckcen.be>
Cc: tech-talk at aps.anl.gov
Subject: RE: New to EPICS - v4 questions

 

Kay, thanks for the very nice summary.

 

I’ll just add a few more reasons for using PVAccess for areaDetector NDArrays.

-          The data type of the array seen by the PVAccess client will change dynamically as the source data type changes.  One example is when a camera is switched between 8-bit and 16-bit modes.

-          PVAccess supports data compression.  areaDetector NDPluginCodec and the ImageJ and Python viewers support the blosc, lz4, bitshuffle/lz4, and jpeg codecs.

-          PVAccess provides all of the additional NDAttribute metadata associated with the array.  These might include the storage ring current, the camera exposure time, etc.

 

Mark

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Kasemir, Kay via Tech-talk
Sent: Friday, March 5, 2021 10:48 AM
To: tech-talk at aps.anl.gov; Stainer Tom <Tom.Stainer at sckcen.be>
Subject: Re: New to EPICS - v4 questions

 

Good questions.

At this time, I think the answers all describe an in-between scenario.

 

Bottom line is that there's no need to panic.

Simply use EPICS IOCs as they have always been used, with Channel Access.

All the IOCs and all the client tools fully support that.

 

If you create an IOC with a recent EPICS 7 release, it will by default also include a PVAccess server.

At this time, you can probably safely ignore that, but keep it enabled to be ready for the future.

Some clients can already switch to PVAccess, and for the most part that works the same as Channel Access, but right now there's likely no reason to fully switch over.

 

There are two scenarios where using PVAccess offers big advantages:

When you use the AreaDetector to serve images, doing that over PVAccess means that one PV carries not only the bits in the image but also metadata like size, color mode. So new clients can right away display the image. With Channel Access, the image PV only has the bits, and you need to configure many clients manually to tell them about the image size etc. PVA is also faster for images than Channel Access.

 

The other advantage of PVA is when you write your own, non-IOC server for custom data. With PVA, you can transfer your own custom data structures, which you couldn't do with CA. There are demonstrations for combining fields of "normal" records into such custom structures, but I think it's fair to say that we're still exploring how that would be used and what it should look like in the final incantation. This would not be a time to replace all your basic records and PVs with custom structures just for the fun of it.

 

At this time a full switch to PVA is likely limited by not all tools fully supporting it, and the absence of a well-tested network gateway. The one that's in common use for example uses new UDP ports when replying to search requests. Can't use that via a firewall.

You'll also notice that we just developed a second set of server and client libs for C++ and Java. While the first ones were great for demonstrating the protocols and figuring several details out, the "updates" focus on the specific advantages of C++ (pvxs) respectively Java (as used in CS-Studio/phoebus), so they have an API that's more natural to those who use C++ resp. Java, while the original implementations concentrated on offering the exact same API, thus ending up with the lowest common denominator of the two languages.

 

Bottom line, for an "end user" I'd suggest to keep PVA 'enabled', maybe try it for Area Detector images, and be prepared to eventually switch over, but for now concentrate on CA for most of the PV traffic.

 

-Kay

 

 

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Stainer Tom via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, March 5, 2021 11:10 AM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: [EXTERNAL] New to EPICS - v4 questions

 

Hi,

 

I am new to EPICS and to the community and therefore I apologise in advance if my question is somewhat elementary, but I have been struggling to understand EPICS v4 fully from documentation alone.

 

It is quite clear that most documentation available online is focused on Channel Access and EPICS v3, however, since I am new to EPICS I would like to start learning from the latest (and greatest?) version and protocol i.e v4 & PVAccess. I understand that v7 supports both CA and PVA, that is clear, but what is not so clear is how to use PVAccess when compared to CA.

 

For example, I have come across the exampleCPP repository (https://github.com/epics-base/exampleCPP) focused on defining records, servers, and clients, using the pvDatabase and pvAccess interfaces. In addition, I have also come across the PVXS library (https://github.com/mdavidsaver/pvxs) which offers an alternative approach to this (and seems to avoid the concept of record and databases altogether?). While there are some nice examples and some short explanations of each it has still been a struggle to figure out how they work and to understand how it relates to the v3 approach. The same goes for the python packages: pyepics, pvapy and p4p (and others). As a newcomer it is quite confusing to see many different approaches and packages used but no clear entry point on which one should be used in different circumstances, and which libraries/packages support which functionality i.e. access control, etc.

 

My initial questions are:

·         Is PVXS intended to replace pvDatabase, pvAccess et al?

·         Of the C++ and Python packages & libraries which ones are most feature complete in terms of the v3 approach?

·         What is the best way to get started and start building clients, servers, IOCs?

·         How does PVA and the nested datastructures work with the process database (file based record definition)?

·         Going forward which packages are likely to be maintained and supported on both the C++ and python sides?

·         Can I altogether ignore v3 and Channel Access when starting from scratch and just use v4 for everything? Is this the recommended approach for newcomers? Are there any limitations to using v4 compared to v3?

 

Any help you can provide on this is much appreciated.

 

Kind regards,

Tom