AI-driven development of device support.

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

This is my reply to Kay's entry in other tech-talk thread, attached below. By some reason I was not able to use Reply All there.

First of all many thanks for everyone, contributed to that thread. It was tremendous help in our transition from custom control to EPICS.

Kay, I generally agree with all points except  #4.
Maybe I elaborate more on my real experience with such development.
We have hundreds of different oscilloscopes in our complex, all served by our custom-made control infrastructure. My task was to try to develop support for modern brands for our future EPICS infrastructure.

1. Initially I made a simple python PVA server for RIGOL DHO924. Its programming manual is 430 pages. It was done from scratch using inline help from Gpt5.2 Codex. It was field debugged and tested.
2. Then I asked Github Copilot to build support for Tektronix MSO46 using Rigol repository as a template and programming manual with 2000 pages. The result was surprisingly good. The server worked immediately, publishing required PVs. Of course it required serious manual tuning for couple of days. After that it was successfully field-tested with real instrument.
3. The server for RIGOL was updated and extended to serve as better template. I added control GUI page, based on my lightweight Control GU (pypeto).
4. Then I asked to do the same for LeCroy brand of scopes (manual with 820 pages) using updated template from RIGOL. The server was created and most of PVs were functional with real scope right away. Even control page was workable.

Summary: In less than a week I was able to develop support for many types of scopes. Otherwise it would take several months of development.

Regards, Andrey

----------------------------------------------------------------------------

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.