Re: Does every DB record need to produce a PV?

["Sukhanov, Andrei via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Dave.
To fully control a device parameter, the only necessary access modes are: 1) get() - to get parameter property, 2) put(): to set parameter property,  3) monitor(): to react, when parameter changes and 4) info(): for introspection.
The database records are internal features of IOC implementation. Using p4p client you can access all PV properties from IOCs. Using p4p server you create PVs, with all its properties accessible from IOC clients.
In our demo installation we have 10K+ PVs, published by p4p servers and they are all properly handled by Phoebus and Archiver Appliances. The publishing throughput maxes out at 1400 MB/s per one CPU core.

Concerning support modules. In python, pretty much all protocols are readily available. To support class of devices (e.g. oscilloscopes) we are using AI agents, it saves months of development. 

/Andrey

---

From: David Bracey <dbracey at fnal.gov>
Sent: Monday, February 16, 2026 12:37 PM
To: Sukhanov, Andrei <sukhanov at bnl.gov>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>; Johnson, Andrew N. <anj at anl.gov>
Subject: Re: Does every DB record need to produce a PV?

 

Hi Andrew and Andrei, thank you for the information, it is much appreciated. Andrei, I had not realized that p4p IOC’s did not have an internal database. This is similar to some work we have done with Michael Davidsaver’s PVXS server classes,

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

Hi Andrew and Andrei,  thank you for the information, it is much appreciated.

 

Andrei, I had not realized that p4p IOC’s did not have an internal database.  This is similar to some work we have done with Michael Davidsaver’s PVXS server classes, where we programmatically create PV’s directly connected to data sources.

 

This leads me to wonder how many IOC’s  would opt-out of having a database, if that was an option?  I had just assumed that it was strongly desired, given how much functionality is built around it – especially communicating with support modules attached to a given IOC.

 

From: Sukhanov, Andrei <sukhanov at bnl.gov>
Date: Monday, February 16, 2026 at 11:18 AM
To: David Bracey <dbracey at fnal.gov>, tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>, Johnson, Andrew N. <anj at anl.gov>
Subject: Re: Does every DB record need to produce a PV?

[EXTERNAL] – This message is from an external sender

Hi Dave,
FYI, in python implementations of EPICS (p4p for PVA or caproto for CA) there is no database records. The PV-space is not crowded at all. It contains only PVs representing actual device parameters.

/Andrey Sukhanov,
Collider Accelerator Department.
Brookhaven National Laboratory. 

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Johnson, Andrew N. via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, February 16, 2026 11:58 AM
To: David Bracey <dbracey at fnal.gov>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Does every DB record need to produce a PV?

 

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

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

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