Hello all,
The LLM into driver discussion notwithstanding. My group often uses an underscore before the prefix to denote internal PVs. The idea is simply that the _$(PREFIX)$(RECORD) entries are not meant for users to interact with. We use those, for example, when
we need a (a/s)calcout that does some internal calculation whose calculation goes to the PV we intend the user to read. This can be done a few reasons, e.g.:
- making use the ZNAM, ONAM, etc so the value is interpretable to users,
- the calculation is an intermediate step that used for several different other calculations
- a way to overcome char limits from using a single calc), etc.
Our IOCs tend to come with a lot of "fluff" PVs that we generally don't interact with and do "clutter" our dbl. These come from the several modules we build into our IOCs (i.e., iocStats, autosave, recsync, etc) and some bundle even more features that
are seldom used (like ADPlugins in some of our IOCs). But my counterargument is that:
- we can't load records after iocInit, so it's better to load pre-emptively instead of having to restart IOCs because you need something that is not available.
- most of our users are not interacting with a list of PVs, but rather screens that we develop
- we could trim down the number of records by loading only what is necessary, but even that requires careful evaluation, time and effort and often users don't know themselves if they'll need a feature or not (or they are sure they don't and next thing
you know they need it right away).
I agree that when trying out a new driver/module/etc, the number of records can be quite overwhelming, especially when the documentation is sparse. But I have found that driver developers in the EPICS community are usually open and willing to help out,
I certainly have done my share of asking the local AD and SynApps gurus when I get stumped.
I tend to use a small fraction of the PVs that the drivers supply, but as long as it is able to do what it is meant to do, I'd prefer to keep drivers as flexible as possible, this usually means having a larger number of (possible) records to load. IMHO,
that is certainly easier than having to maintain our fork or redevelop a new driver. One alternative is to create your own db/substitution files that contain only the necessary subset of features you'd like. While I find this to be counter-productive most
of the time (as expressed above), I do that to some of our IOCs.
Pedro Nariyoshi
|
Software Controls Engineer
Facility for Rare Isotope Beams
Michigan State University
640 South Shaw Lane
East Lansing, MI 48824, USA
Tel. 517-908-7352
Email: nariyosh at frib.msu.edu
|
|
From: Kay Kasemir
Sent: Wednesday, February 18, 2026 10:13 AM
To: tech-talk at aps.anl.gov
Subject: Re: [EXTERNAL] Does every DB record need to produce a PV?
Note that the following was partially created by the AI ASSISTANT 2.0 Beta using the "o3-mini” LLM
----
Your roadmap oversimplifies a complex integration task and may give the false impression that AI-assisted coding can seamlessly replace deep domain knowledge
and careful system integration. Here are some concerns:
-
Although a 50‐page manual with around 200 parameters might be amenable to some degree of automation, using GitHub Copilot in this context risks missing important nuances. The detector’s configuration, timing requirements, or
error handling strategies may not be fully captured by merely templating from the epicsdev module.
-
Code generation tools like Copilot, while helpful, often produce boilerplate or even misleading code snippets without understanding the hardware-specific quirks of a detector. The approach appears to rely too much on automated
suggestions without a robust review to account for hardware-specific requirements.
-
The roadmap assumes that the programming task is essentially a matter of translating parameters into Python “PVs” with a one-to-one mapping. In practice, integrating with complex hardware typically involves dedicated communication
protocols, real-time constraints, and error recovery which require careful design and testing—not just a pull request review cycle.
-
While debugging with the real device might be simpler in Python than in C/C++, this assumes that the abstraction layer introduced is both stable and performant enough for production use. Handling detector data with separate
PVAccess servers further complicates the system integration, and the approach does not address how to manage inter-module communication or reliability issues.
-
Relying on a link to the manual in the prompt expects that Copilot (or similar tools) will effectively parse 50 pages of domain-specific information and map it to correct code. This level of semantic understanding is optimistic,
and manual intervention will likely be required to ensure accuracy.
In summary, while the proposed approach is a creative starting point, it underestimates the challenges of translating hardware specifications into robust,
high-performance software. A more effective strategy would involve a detailed analysis of the manual, collaboration with domain experts, and incrementally prototyping the system with comprehensive tests that simulate the behavior of the real device.
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Sukhanov, Andrei via Tech-talk <tech-talk at aps.anl.gov>
Date: Tuesday, February 17, 2026 at 4:18 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?
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, 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:
-
Create a new GitHub repository.
-
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.
-
Copilot generates an initial pull request.
-
Review the code and request modifications or improvements as needed (this may require several iterations).
-
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?
This Message Is From an External Sender
This message came from outside your organization.
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?
This Message Is From an External Sender
This message came from outside your organization.
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.
This Message Is From an External Sender
This message came from outside your organization.
Hi Dave,
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
|
