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  2025  <2026 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  2025  <2026
<== Date ==> <== Thread ==>

Subject: Re: Does every DB record need to produce a PV?
From: "Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>
To: David Bracey <dbracey at fnal.gov>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Mon, 16 Feb 2026 16:58:37 +0000
Hi Dave,

Over Channel Access I believe it’s possible for a record to belong to an Access Security Group that has READ access disabled for some or all users. However this is (almost?) never used and could confuse and/or crash many if not all CA client programs when accessing those PVs since the record’s fields can still be connected to (they aren’t actually hidden from clients), but they won’t return any data or metadata.

If you could make some records only visible to a subset of users there is a danger that multiple records could exist with the same name, but a conflict would only be visible to users who can see both definitions. How should the client code decide which server to connect to in that case?

I believe the PVA existing servers have no support for disabling READ access that way, so any client can read and subscribe to any PV. That may not be the case for servers running the Secure PVA protocol though, the group working on them may have built record hiding into that. Someone else would have to answer that question though, and explain how they propose to resolve the above issue if they do support record hiding.

EPICS’s use of a flat name-space is why developing and enforcing a hierarchical naming convention is very important when designing EPICS-based control systems. I recommend searching for previous tech-talk discussions about that topic, or asking specifically about that (almost every large site should have done that).

At the APS one of our conventions is that record names ending in an underscore character “_” are intended to be private to the IOC implementation (as is common in Python I believe). By not actually hiding those PVs they remain accessible for debugging; they can be configured to be read-only, or only writable by the IOC developer(s).

HTH,

- Andrew


-- 

Complexity comes for free, Simplicity you have to work for.


On 2/16/26, 10:15 AM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:

A naïve user of EPICS would think that every database record of every IOC gets exposed as a PV.

 

Is this truly the case?  If so, has any mechanism for hiding the “internal” records ever been discussed?

 

The PV-space of an EPICS deployment seems very crowded.

 

Dave Bracey

AD Controls

Fermi National Accelerator Laboratory

 


Replies:
Re: Does every DB record need to produce a PV? Sukhanov, Andrei via Tech-talk
References:
Does every DB record need to produce a PV? David Bracey via Tech-talk

Navigate by Date:
Prev: Re: EPICS CA and PVA across subnets James Smedinghoff via Tech-talk
Next: Re: Does every DB record need to produce a PV? Sukhanov, Andrei 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  2025  <2026
Navigate by Thread:
Prev: Does every DB record need to produce a PV? David Bracey via Tech-talk
Next: Re: Does every DB record need to produce a PV? Sukhanov, Andrei 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  2025  <2026
ANJ, 19 Mar 2026 · Home · News · About · Talk · Base · Modules · Extensions ·
· Distributions · Download · Documents · Links · Licensing ·