Experimental Physics and Industrial Control System
|
Hi Dave,
When you say PVXS, are you really asking about building IOCs that provide both a Channel Access and PV Access server, or about using the specific PVXS implementation instead of the original pvAccessCPP?
You don't need PVXS to create IOCs that can talk the PVAccess protocol. PVXS started as a reimplementation of the original C++ client and server code for the PVA protocol but using a better internal architecture and written in modern C++.
It can communicate over IPv6 now, and future releases will be able to use TLS for much improved security, but those won't change the underlying IOC code significantly.
- Andrew
On 3/20/24, 12:06 PM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:
> I’d say the prevalent scenarios would still be IOCs with records, and PVAccess is then
> used just like Channel Access. That’s why we have normative types which mostly mirror
> the DBR_.. types, and clients like CS-Studio that can fairly transparently switch between
> the two protocols.
I guess I’m unsure what the value of PVXS would be in a scenario like that? If you are starting from a normal EPICS IOC project, and adding PVXS, what is PVXS doing for you? You are still defining your PV’s in
terms of records in DB files, etc.
I can see that if you are building an IOC for an embedded architecture, the EPICS build system adds value in being able to handle the different toolchains and build products, etc.
However, at the moment I’m looking at making a soft-IOC (i.e. on intel/amd64 linux), and I’m seeing the opportunity to use a simpler (and contemporary) build system and construct PV’s at run-time, rather than use
DBD/DB which need to be consumed at build.
I’m wondering if this is a compelling idea at all, or a poor idea?
From: Kasemir, Kay <kasemirk at ornl.gov>
Date: Wednesday, March 20, 2024 at 11:43 AM
To: Dave Bracey <dbracey at fnal.gov>, tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: PVXS IOC Philosophy
[EXTERNAL] – This message is from an external sender
I’d say the prevalent scenarios would still be IOCs with records, and PVAccess is then used just like Channel Access. That’s why we have normative types which mostly mirror the DBR_.. types, and clients like CS-Studio
that can fairly transparently switch between the two protocols.
With PVAccess you do now have the option to use new types. It allows you to transfer site-specific data over the same protocol, but you can’t expect generic widgets to fully understand your data. That mostly means
you need to create both the server and the client, which you can do in python etc.
The new ‘group’ feature does allow you to create custom types by on combining data from records, but for the client side you’re then again on the hook to create for example a python script to understand that custom
data.
So bottom line the goal here should not be that every piece of information now needs to be placed in a newly developed data type with its own custom server and client. On the contrary, the existing record types,
the normative types to read/write them, and generic clients like display managers are meant to fill most of your needs, as was the case with EPICS for the last 30 years.
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Dave Bracey via Tech-talk <tech-talk at aps.anl.gov>
Date: Wednesday, March 20, 2024 at 12:30 PM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: [EXTERNAL] PVXS IOC Philosophy
Going forward, is the philosophy of PVXS to create PV’s programmatically, per the examples (i.e. https://mdavidsaver.github.io/pvxs/example.html#mailbox-server)
?
Or, is the idea of creating PV’s by providing record definitions and instances via DBD / DB files still intended to be relevant?
One can create a hybrid IOC (https://mdavidsaver.github.io/pvxs/ioc.html)
and still take in DBD/DB files, but this doesn’t seem to really involve PVXS, at least from the developer’s perspective (other than the fact that QSRV2 makes it work).
As always, I may be completely wrong about any of that, so feel free to let me know.
Dave Bracey – Fermilab AD Instrumentation
|
- Replies:
- Re: PVXS IOC Philosophy Dave Bracey via Tech-talk
- References:
- PVXS IOC Philosophy Dave Bracey via Tech-talk
- Re: PVXS IOC Philosophy Kasemir, Kay via Tech-talk
- Re: PVXS IOC Philosophy Dave Bracey via Tech-talk
- Navigate by Date:
- Prev:
Re: PVXS IOC Philosophy Johnson, Andrew N. via Tech-talk
- Next:
Re: PVXS IOC Philosophy Dave Bracey via Tech-talk
- 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>
- Navigate by Thread:
- Prev:
Re: PVXS IOC Philosophy Dave Bracey via Tech-talk
- Next:
Re: PVXS IOC Philosophy Dave Bracey via Tech-talk
- 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>
|
ANJ, 20 Mar 2024 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|