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

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

The APS Accelerator IOCs currently make well over 2,000,000 unique record names available to our CA clients. The total number of valid, unique PV names that can be constructed from those records is actually much larger than you might think though; in addition to adding between about 40 and 300 field names to each record name, EPICS IOCs since 3.15 have supported server-side filters that let the client append parameterized channel filters to the PV name as well.

Naturally we couldn’t sensibly manage that many names without a centralized naming authority, which is largely administrative but de-duplication is also enforced by our name-servers. During the recent APS Upgrade we reviewed the proposed PV names for each IOC subsystem against our naming convention, for which we have a website that makes picking PV and device names quite straightforward. Our CA name-servers were added to allow traffic to cross subnets, speed up client connections and reduce the search load on our IOCs, but they also detect name duplication and prevent clients in other subnets from ever seeing it.

The EPICS IOC gives our control system developers excellent remote visibility into the lower levels of our machine’s operation, without our having to think much about making internal state visible for debugging problems in the live machine. All software and control systems have bugs, but because they can see anything that appears in a record field, the experts on our subsystems can frequently make configuration adjustments to their databases if needed to recover from problems without having to restart the IOC.

How much visibility do the Python servers provide into their internals? Can you make live changes to them to fix machine problems at 3am without bringing down the beam?

- Andrew

-- 

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

On 2/17/26, 11:35 AM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:

I would think the basic problem with a system with many names and no centralized naming authority is namespace pollution and potential duplication.

 

I feel that the practice of hierarchical names is not good for usability.  Our operators speak the names of devices to each other all day long.  I can’t imagine them having to say “colon … colon … colon … colon”.

 

From: Sukhanov, Andrei <sukhanov at bnl.gov>
Date: Tuesday, February 17, 2026 at 11:12 AM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>, David Bracey <dbracey at fnal.gov>, Mark Rivers <rivers at cars.uchicago.edu>
Subject: Re: Does every DB record need to produce a PV?

[EXTERNAL] – This message is from an external sender

Mark, Kai,
The multitude of the PVs, not related to real device parameters, may pose real trouble for end users. For example, we were provided with an EPICS-driven PSC (power supply controller). The controller itself has ~200 of control parameters. But the IOC hosts ~2000 of PVS. This is just not manageable without tight support from original designers.

/Andrey Sukhanov,

Collider-Accelerator Department, BNL.

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, February 17, 2026 11:54 AM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>; David Bracey <dbracey at fnal.gov>
Subject: Re: Does every DB record need to produce a PV?

 

Hi Dave, A naïve user of EPICS would think that every database record of every IOC gets exposed as a PV. Note that there is not a 1: 1 relationship between records and PVs. Even simple records like "bi" expose many record fields as

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

Hi Dave,

 

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

 

Note that there is not a 1:1 relationship between records and PVs.  Even simple records like "bi" expose many record fields as PVs, not just the .VAL field.  For example, the .SCAN, .ZNAM, .ONAM, .SDIS, .DESC, and many more.  More complex records like the "motor" record have dozens of PVs, like .VELO, .ACCL, .STOP, .DVAL, .RVAL, etc.

 

Mark

 

 

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of David Bracey via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, February 16, 2026 10:15 AM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Does every DB record need to produce a PV?

 

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