| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: New to EPICS - v4 questions |
| From: | "Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov> |
| To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>, Stainer Tom <Tom.Stainer at sckcen.be> |
| Date: | Fri, 5 Mar 2021 16:47:55 +0000 |
|
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 |