EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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: PVXS IOC Philosophy
From: "Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov>
To: Dave Bracey <dbracey at fnal.gov>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Wed, 20 Mar 2024 16:42:54 +0000

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 Kasemir, Kay via Tech-talk
Re: PVXS IOC Philosophy Dave Bracey via Tech-talk
Re: PVXS IOC Philosophy Johnson, Andrew N. via Tech-talk
References:
PVXS IOC Philosophy Dave Bracey via Tech-talk

Navigate by Date:
Prev: PVXS IOC Philosophy Dave Bracey via Tech-talk
Next: Re: PVXS IOC Philosophy Kasemir, Kay 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: PVXS IOC Philosophy Dave Bracey via Tech-talk
Next: Re: PVXS IOC Philosophy Kasemir, Kay 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 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·