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

[Timo Korhonen via Tech-talk <tech-talk at aps.anl.gov>]

A bit late to the game…

 

Mark here, and others in earlier posts have exactly described the right points.

 

Custom programming may seem attractive when you have a simple problem to solve.

But then the reality hits…handling all kinds of error situations, providing functionality that you did not foresee immediately, handling lots of almost-identical systems with different parameters,…

 

Like Anders mentioned in another mail, we at ESS have at the moment about 12 million records - live. (without counting the record fields…)

It obviously needs some infrastructure to work, but it is manageable, and we do not have issues with stability, at least major ones.

We probably could optimize and reduce the number – but it has not been necessary so far, delivering the controls has been a priority.

 

Maybe my imagination is limited but I see absolutely no way how we could have achieved this with writing custom code – even with help of AI – for each case we must deal with.

 

Python-based servers may have their place in some applications, but they are nowhere near a replacement to proper IOCs with field-proven and stable code.

 

Timo

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Tech-talk <tech-talk at aps.anl.gov>
Reply to: Mark Rivers <rivers at cars.uchicago.edu>
Date: Tuesday, 17 February 2026 at 22:34
To: "Hartman, Steven" <hartmansm at ornl.gov>, David Bracey <dbracey at fnal.gov>, "Sukhanov, Andrei" <sukhanov at bnl.gov>
Cc: Tech-talk <tech-talk at aps.anl.gov>
Subject: Re: [EXTERNAL] Does every DB record need to produce a PV?

 

OK, now please provide:

 

• Statistical information on the maximum and minimum counts, position of the centroid, and time-series of all of the above in a user GUI

• Send lz4 or bslz4 compressed data from the detector directly to an HDF5 file and a PV access viewer, but decompress the data also so you get the statistical information.

• The HDF5 file also needs to contain user-configurable metadata including the ring current, position of all important beamline motors, sample information, etc.  This needs to be configurable by a user with no programming expertise.

• Some users will want to save TIFF images instead because that is what their diffraction data will require.

• Some users will want to plot the net intensity in an ROI as they scan in reciprocal (diffraction) space so they can find the Bragg peaks

 

They get all of this and much more today without writing a single line of code.

 

Mark

 

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Sukhanov, Andrei via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, February 17, 2026 3:17 PM
To: Hartman, Steven <hartmansm at ornl.gov>; David Bracey <dbracey at fnal.gov>; Sukhanov, Andrei <sukhanov at bnl.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: [EXTERNAL] Does every DB record need to produce a PV?

 

Mark, concerning your reply:

>To provide another counter-example I just checked the IOC for a >Dectris Eiger detector....

The Dectris Eiger Programming Manual is about 50 pages long and describes ~200 real parameters. I would approach support for the Dectris Eiger detector in Python using the following roadmap:

1. Create a new GitHub repository.

2. Use GitHub Copilot to generate Python support for the Dectris Eiger detector, using the epicsdev module as a template and providing a link to the Programming Manual. A well-structured and detailed prompt would improve the results.

3. Copilot generates an initial pull request.

4. Review the code and request modifications or improvements as needed (this may require several iterations).

5. Perform a final review and merge the pull request.

As a result, you would obtain a ready-to-run Python module serving ~200 PVs.

Final tuning with the real device may take several days. Debugging with the real hardware is significantly simpler in Python than in C/C++.

Processing detector data would be better handled by separate PVAccess servers.

Regards, Andrey

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Sukhanov, Andrei via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, February 17, 2026 2:18 PM
To: Hartman, Steven <hartmansm at ornl.gov>; David Bracey <dbracey at fnal.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: [EXTERNAL] Does every DB record need to produce a PV?

 

From my perspective, an EPICS IOC with ~2000 PVs lacking descriptions, for a device without a Programmer’s Manual, is unmanageable. From: Hartman, Steven <hartmansm@ ornl. gov> Sent: Tuesday, February 17, 2026 12: 58 PM To: Sukhanov, Andrei

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

From my perspective, an EPICS IOC with ~2000 PVs lacking descriptions, for a device without a Programmer’s Manual, is unmanageable.

---

From: Hartman, Steven <hartmansm at ornl.gov>
Sent: Tuesday, February 17, 2026 12:58 PM
To: Sukhanov, Andrei <sukhanov at bnl.gov>; David Bracey <dbracey at fnal.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: [EXTERNAL] Does every DB record need to produce a PV?

 

What makes you think this is unmanageable? There are plenty of counter examples of existing facilities where this works. -- Steven Hartman hartmansm@ ornl. gov On Feb 17, 2026, at 12: 12 PM, Sukhanov, Andrei via Tech-talk <tech-talk@ aps. anl. gov>

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

What makes you think this is unmanageable? There are plenty of counter examples of existing facilities where this works.

 

-- 

Steven Hartman

hartmansm at ornl.gov

 

 

On Feb 17, 2026, at 12:12 PM, Sukhanov, Andrei via Tech-talk <tech-talk at aps.anl.gov> wrote:

 

This Message Is From an External Sender

This email was sent from a non-ORNL address. If suspicious, use the Report Phish button in Outlook.

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?

 

This Message Is From an External Sender 

This message came from outside your organization. 

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