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
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.
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