RIO EPICS device support application case study on an ion source control system (ISHP)

Diego Sanz; Inari Badillo; I\~nigo Arredondo; Jes\'us Vega; Josu Jugo; Mariano Ruiz; Mikel Eguiraun; Rodrigo Castro

REVIEW 4 major objections 5 minor 8 references

RIO EPICS device support application case study on an ion source control system (ISHP)

T0 review · 4 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that an operational ion source control system can be moved from LabVIEW-based EPICS servers to Linux EPICS IOCs by adding base registers and renaming I/O registers in the FPGA code, with the original control logic still…

desk verdict A useful first-application engineering case study of an EPICS RIO driver, but the load-bearing claim that the FPGA behavior is unchanged after adaptation is asserted rather than demonstrated. read the letter →

arxiv 2501.18214 v1 pith:XCZA2UZ7 submitted 2025-01-30 physics.ins-det hep-ex

Diego Sanz , Mariano Ruiz , Mikel Eguiraun , Iñigo Arredondo , Inari Badillo , Josu Jugo , Jesús Vega , Rodrigo Castro This is my paper · ORCID

classification physics.ins-dethep-ex

keywords EPICSFPGAPXIRIOtechnologyFlexLabVIEWionsourcecontroldevicesupport

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper reports a real case study in which the control system of an electron cyclotron resonance ion source (ISHP) is migrated from LabVIEW-based EPICS servers to Linux EPICS Input/Output Controllers (IOCs), using a device-support layer called NIRIO-EDS. The central claim is that RIO/FlexRIO FPGA devices need only small, mechanical changes to their LabVIEW code - adding base registers and renaming I/O registers according to design rules - before they can be controlled and monitored as standard EPICS devices over channel access. The paper states that this preserves the previous system's behaviors: data acquisition, motor control logic, and trigger sequencing for the RF generator and beam diagnostics all remain in the FPGA firmware and keep functioning. If true, this is the first demonstration of the methodology on an operating ion source, and it gives other laboratories a concrete recipe for integrating RIO/FlexRIO hardware into full EPICS environments without rewriting FPGA logic.

What carries the argument

The central mechanism is NIRIO-EDS, an EPICS device-support layer built on the asynDriver library, a low-level EPICS communication framework, which views each RIO/FlexRIO FPGA as a black box of I/O registers and DMA channels. The coreDAQ profile imposes a fixed set of base registers and naming rules on the LabVIEW FPGA code. The argument runs through this identity: adding the base registers and renaming controls and indicators is enough to make a bespoke RIO design describable, and once describable, the driver can auto-generate the record database and startup files, assign each EPICS process variable to its corresponding register, and launch a DMA thread per channel to stream data to host RAM. The migration is carried by the fact that the LabVIEW code for FPGA can be recompiled to a bitfile whose resource map is captured by a C API generator tool, giving the Linux IOC everything it needs to configure and communicate with the device.

What would settle it

Replay one complete ISHP operating scenario under the old LabVIEW-based IOC and under the new NIRIO-EDS Linux IOC on the same hardware, logging every process variable and FPGA register, and compare trigger timing, motor-command sequences, and acquired data sample counts. Any difference in timing, order, or sampled data would show that adding base registers and renaming controls did not actually preserve the original behavior.

Watch

Extended reading notes

Core claim

The migration treats each RIO device as a black box with scalar and vector I/O registers plus DMA channels, described to EPICS through the coreDAQ profile of NIRIO-EDS. The existing ISHP FPGA code is adapted to the design rules in two steps: the base registers required by the driver are added so it can identify FPGA resources and clock information, and every control and indicator in the LabVIEW code is renamed so each I/O register conforms to the naming scheme. Once the code is recompiled, the bitfile and the file generated by the LabVIEW C API tool are handed to NIRIO-EDS, which configures the FPGA, binds every process variable to its register, and launches one thread per DMA channel to move acquired data to host memory. The paper reports that all FPGA code and features from before - data acquisition, motor control logic, and the trigger sequence for RF and diagnostics - remain the same and function properly, and that the external LabVIEW IOC machine is no longer needed. On the paper's own terms, this makes NIRIO-EDS a working bridge between bespoke RIO/FlexRIO FPGA configurations and full EPICS distributed control on Linux.

Load-bearing premise

The load-bearing premise is that adding the NIRIO-EDS base registers and renaming the LabVIEW controls and indicators leaves the original FPGA control logic functionally unchanged; the paper asserts this without providing a regression test or independent verification.

Editorial extensions

If this is right

RIO/FlexRIO FPGA designs can be brought into a Linux EPICS environment by mechanical changes to the LabVIEW code, with no need to re-implement the control logic in another language.
The same NIRIO-EDS support can expose data acquisition, motor control logic, and trigger sequencing of an ion source through standard EPICS channel access, enabling distributed control and monitoring.
The external computer used to complete EPICS features under the old LabVIEW-based server is no longer required, since the Linux IOC itself is a full EPICS server.
Because the FPGA logic is preserved, the real-time behavior established in the previous system carries over to the migrated system without redesign.
The methodology becomes a reusable recipe for other RIO/FlexRIO devices in large experimental facilities, requiring only that the design rules be applied before compiling the FPGA bitfile.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Beyond the paper: the same rename-and-add-registers recipe should transfer to other LabVIEW FPGA designs, but only if all control state the host needs is exposed through the registers and DMA channels the driver can see; designs with hidden internal FPGA state might not survive the migration unchanged.
Beyond the paper: a regression suite that replays a full operating cycle under the old and new IOCs would turn the functional-invariance assertion into a testable property; the paper gives no such comparison.
Beyond the paper: standardizing the coreDAQ profile opens a natural path to other profiles, such as image acquisition, so the migration recipe could cover camera-based diagnostics in the same facilities.
Beyond the paper: reporting the number of renamed registers, compile iterations, and person-hours would let other groups estimate the cost of applying the methodology; the paper only describes the changes as short.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The paper is what it says it is: the first real application of the NIRIO-EDS methodology to an operational ion source at ESS Bilbao. The novelty is not the methodology itself — that was already published by the same group in [7,8] — but the fact that it was taken out of the lab and made to control a live system. For accelerator and fusion control groups using NI RIO hardware, this is a genuinely useful data point: it shows the migration path from LabVIEW-RT/EPICS DSC to Linux EPICS IOCs with relatively small FPGA code changes. The description of the migration steps is clear and the authors are upfront about which parts of the methodology pre-exist this work.

The soft spot is exactly where the reader's stress test lands. The central claim is that adding the NIRIO-EDS base registers and renaming I/O registers leaves the FPGA logic functionally unchanged. The paper gives no diff, no regression test, no side-by-side comparison of beam pulses or motor trajectories between the old LabVIEW IOC and the new Linux IOC, and no quantitative data on timing, throughput, or uptime. The text even wobbles: Section 4 says the driver 'supports most of the previous control features' and then two sentences later says 'All of the code and the features ... remain the same as before.' That is a real tension, and it is not resolved. The screenshot in Fig. 5 shows a beam pulse, but there is no baseline to compare against. Since the driver was developed by the same group that performed the migration, the self-report is plausible but not independently verified.

That said, I would not call this a fatal flaw. For an engineering case study, the qualitative demonstration is often the norm, and the paper is honest that this is the first application rather than a systematic validation. The claims about robustness, scalability, and maintainability do outrun the measurements, but the core feasibility claim — that NIRIO-EDS can drive an operational RIO-based ion source from Linux EPICS — is credible and useful.

My recommendation: send it to peer review, but with a clear request for the authors to either provide a baseline comparison or soften the equivalence claim. A single beam-pulse overlay would already be enough to make the central claim defensible. This paper is for people who are considering the same migration, not for people looking for new driver internals. It deserves referee time, but it needs revision before publication.

Referee Report

4 major / 5 minor

Summary. The paper reports a case study in which the existing LabVIEW-RT/EPICS-based control system of the ESS Bilbao Ion Source Hydrogen Positive (ISHP) is migrated to a Linux (CentOS) EPICS environment using the NIRIO EPICS device support (NIRIO-EDS). The proposed design methodology treats RIO/FlexRIO FPGAs as black boxes with I/O registers and DMA channels, and it requires only renaming LabVIEW FPGA controls/indicators and adding base registers, without changing the original FPGA control logic. The authors claim that this migration preserves the previous capabilities (data acquisition, motor control logic, trigger sequencing for the RF generator and diagnostics) and that the new IOCs are robust, scalable, and maintainable. The evidence consists of a description of the migration steps, a system architecture diagram, and a figure showing an operational session with a beam pulse.

Significance. If the central claim holds, this is the first demonstration of the RIO/FlexRIO design methodology (previously developed by the same group) on an operational ion source, extending the methodology from prototype I-DAQ systems to a real accelerator-control environment. The paper has the strength of being anchored to a concrete, operational facility and it shows a real ACCT beam pulse, which provides some external evidence that the migrated system was used during an experiment. Nevertheless, the demonstration is qualitative and appears largely self-reported by the group that developed both the driver and the methodology, so the novelty is incremental and the evidentiary burden is correspondingly higher.

major comments (4)

[Section 3, paragraph 6] The load-bearing claim that the original FPGA control logic remains functionally unchanged after migration is asserted rather than demonstrated. The text states that the adaptation consists of 'adding all the base registers required by the NIRIO-EDS driver' and 'changing the controls and indicators names', but it provides no diff of the LabVIEW FPGA source, no regression or acceptance test data, no comparison of DMA behavior or timing closure, and no verification that motor trajectories, trigger timings, and acquired waveforms are identical before and after. Since the central result of the paper is that the NIRIO-EDS migration preserves the ISHP functionality, this invariance must be either demonstrated with data or explicitly qualified as an assumption.
[Section 4, first two paragraphs] There is a direct tension between the statements 'the NIRIO-EDS supports most of the previous control features' and 'All of the code and the features that were initially programmed in the FPGAs remain the same as before and functioning properly.' If only 'most' features are supported, then the claim of full functional preservation is not justified; if all features are supported, the word 'most' should be removed. The paper does not provide a list of the previous features, a PV inventory, or a mapping from old EPICS PVs to the new auto-generated records, so the reader cannot determine which features, if any, were dropped or modified.
[Section 4 and Fig. 5] The experimental evidence is limited to a beam pulse screenshot and a GUI/IOC shell screenshot, with no quantitative comparison against the original LabVIEW IOC. There are no timing measurements, throughput figures, uptime statistics, motor trajectory data, or trigger-timing comparisons, and no description of a test procedure. Consequently, the adjectives 'robust, scalable and maintainable' in the abstract and Section 4 are not supported by the presented data; the paper would need at least a minimal regression table or a clear statement that such measurements are outside the scope.
[Section 2, paragraph 3] The description of the original architecture implies that the LabVIEW IOC server was not fully EPICS-compliant and required an external computer for full EPICS features, but the paper does not specify which EPICS features were missing or how the NIRIO-EDS provides them. Without this context, the claimed advantage of the migration (full EPICS compliance) is not concretely tied to the observed system behavior. A short comparison of the old LabVIEW IOC capabilities versus the new NIRIO-EDS IOC capabilities would make the case study more self-contained.

minor comments (5)

[Section 2, paragraph 2] The phrase 'Fig. 1shows' is missing a space; it should read 'Fig. 1 shows'.
[Section 3, paragraphs 4 and 6] The acronym is inconsistently written as 'NIRIO-EDS' and 'NRIO-EDS' (the latter appears in several places, e.g., 'the NRIO-EDS'); the spelling should be unified.
[Section 2, paragraph 3] The sentence 'Complementarily, the cRIO handles all the signals of the RF system' is vague; it is not clear whether these signals include analog waveforms, digital interlocks, or only the RF power-supply controls, and whether the cRIO is also migrated to NIRIO-EDS.
[Section 4, Fig. 5] The screenshot of the beam pulse and the IOC shell is small and appears to be a screen capture rather than a prepared figure; the reader cannot read the PV names or the beam-pulse amplitude/time axes. A larger, annotated version with clearly labeled axes and PV names would improve the paper.
[References] Reference [2] is cited as a 'National Instruments case study' and may not be peer-reviewed; it would be helpful to indicate its access information or to replace it with a publicly available document.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is an engineering case study whose central claims are supported by an operational demonstration rather than by a derivation from its own inputs.

full rationale

The paper contains no equations, no fitted parameters, and no first-principles predictions; it is an engineering case study. The central claim in Section 4, that with short modifications to the LabVIEW FPGA code it was possible to integrate RIO/FlexRIO devices into EPICS environments, is supported by a real operational demonstration: Fig. 5 shows a beam pulse acquired with an ACCT diagnostic, the IOC shell, and the control GUI. The statement in Section 4 that 'All of the code and the features that were initially programmed in the FPGAs remain the same as before and functioning properly' is an empirical invariance assertion. Even though the paper does not provide a regression diff or acceptance-test data, that is an evidence-strength concern, not a circularity. The design methodology and NIRIO-EDS cited as references [4], [7], and [8] are prior work by the same authors, but the present paper is the first application of that methodology to a real, operative system, so those self-citations are not the sole support for the central claim; the external operational test provides independent content. No step in the paper reduces by construction to its own inputs, and no fitted value is renamed as a prediction. Therefore, no significant circularity is identified.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

This is an application case study, so the central claim rests on the correctness of previously published software and on assumptions about the FPGA adaptation. No new physical entity is introduced, and no free parameters are fitted to data. The most important assumption is that renaming registers and adding base registers leaves the ISHP control logic behavior untouched, which is stated in Section 4 with no regression evidence.

assumptions (4)

domain assumption NIRIO-EDS (asynDriver-based device support) correctly maps FPGA registers and DMA channels to EPICS process variables and manages DMA threads.
Invoked throughout Section 3 as the mechanism enabling the migration; the driver's correctness is taken from the authors' prior work [7,8], not re-established in this paper.
domain assumption The RIO/FlexRIO design rules of [7,8] are sufficient for adapting an existing operational FPGA configuration without behavior change.
Section 3 states that only adding base registers and renaming I/O registers is needed; this is an assumption about the methodology's completeness and about the original ISHP design.
ad hoc to paper The original ISHP FPGA control logic, including motor control and trigger sequencing, remains functionally identical after the register renaming.
Section 4 asserts 'All of the code and the features that were initially programmed in the FPGAs remain the same as before and functioning properly' with no test data supporting that invariance.
domain assumption The Linux kernel nirio driver and the CentOS environment are compatible with the PXIe/cRIO RIO hardware used by ISHP.
Section 3 states that the new software unit requires a Linux Red Hat derived version and the use of Linux kernel modules (nirio kernel driver), but no compatibility or stress testing is reported.

how reviews work

0 comments

Cite this review

Pith. "Pith review of RIO EPICS device support application case study on an ion source control system (ISHP)." pith.science (2026). https://pith.science/paper/XCZA2UZ7

@misc{pith2026250118214,
  author       = {Pith},
  title        = {Pith review of: RIO EPICS device support application case study on an ion source control system (ISHP)},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XCZA2UZ7}},
  note         = {Machine review of arXiv:2501.18214}
}

read the original abstract

Experimental Physics and Industrial Control System (EPICS) is a software tool that during last years has become relevant as a main framework to deploy distributed control systems in large scientific environments. At the moment, ESS Bilbao uses this middleware to perform the control of their Ion Source Hydrogen Positive (ISHP) project. The implementation of the control system was based on: PXI Real Time controllers using the LabVIEW-RT and LabVIEW-EPICS tools; and RIO devices based on Field-Programmable Gate Array (FPGA) technology. Intended to provide a full compliant EPICS IOCs for RIO devices and to avoid additional efforts on the system maintainability, a migration of the current system to a derivative Red Hat Linux (CentOS) environment has been conducted. This paper presents a real application case study for using the NIRIO EPICS device support (NIRIO-EDS) to give support to the ISHP. Although RIO FPGA configurations are particular solutions for ISHP performance, the NIRIO-EDS has permitted the control and monitoring of devices by applying a well-defined design methodology into the previous FPGA configuration for RIO/FlexRIO devices. This methodology has permitted a fast and easy deployment for the new robust, scalable and maintainable software to support RIO devices into the ISHP control architecture.

Figures

Figures reproduced from arXiv: 2501.18214 by the authors.

**Figure 1.** Schematic structure of the ISHP control system architecture. The system is divided into the areas of high voltage platform and ground. The system is managed by two PXI chassis and one cRIO for the control tasks, as well as several PLCs in charge of safe operation. in order to be able to support a diversity of experiments and equipment. It implies that its control system has to be very flexible to incorporate new ha… view at source ↗

**Figure 2.** RIO device is observed as a black box with I/O registers and DMA channels by the NIRIO-EDS [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** The IOC EPICS software architecture based on the NIRIO-EDS, which interfaces all FPGA resources with the corresponding PVs. obtain specific information from the hardware configured into the FPGA. This information is related to the number of analog inputs packaged by the DMA channel such as the clock frequency with which the sequential logic hardware will be fed, etc [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: Steps to configure a RIO device, to be supported by the NIRIO-EDS. and supported by the NIRIO-EDS, has satisfied the migration and integration with a Linux software environment. With short modifications to the LabVIEW code for FPGA in order to describe the FPGA behavio…

**Figure 5.** Figure 5: The new EPICS IOCs implemented using RIO/FlexRIO design methodology supported by the NIRIO-EDS, working on a real case application for the ESS Bilbao ISHP [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

8 extracted references · 8 canonical work pages

[1]

Arredondo,M

I. Arredondo,M. Eguiraun, J. Jugo, D. Piso,M. del Campo, T. Poggi, et al., Adjustable ECR ion source control system, in: Real time conference 2014, Nara, Japan, 2014

work page 2014
[2]

Arredondo, M

I. Arredondo, M. Eguiraun, D. Piso, M. del Campo, J. Feuchtwanger, G. Harper, et al., Sistema de Control de la fuente de iones ISHP, in: National Instruments case study, 2013

work page 2013
[3]

Eguiraun, J

M. Eguiraun, J. Jugo, I. Arredondo, M. del Campo, J. Feuchtwanger, V. Etxebarria, et al., ISHN ion source control system. First steps toward an EPICS BASED ESS- Bilbao accelerator control system, IEEE Trans. Nucl. Sci. 60 (April (2)) (2013) 1280–1288

work page 2013
[4]

M. Ruiz, J. Vega, R. Castro, D. Sanz, J.M. López, G. de Arcas, et al., ITER Fast Plant System Controller prototype based on PXIe platform, Fusion Eng. Des. 87 (12) (2012) 2030–2035

work page 2012
[5]

Long, M.P

C.D. Long, M.P. Stockli, T.V. Gorlov, B. Han, S.N. Murray, T.R. Pennisi, Control system for the Spallation Neutron Source H-source test facility Allison scanner, Rev. Sci. Instrum. (2010) 02B722

work page 2010
[6]

Payne, P.G

S.J. Payne, P.G. Barnes, G.M. Cross, A.H. Kershaw, N. Leach, A. Pertica, et al., Beam diagnostics at ISIS, 2008

work page 2008
[7]

D. Sanz, M. Ruiz, R. Castro, J. Vega, J.M. Lopez, E. Barrera, et al., Implementation of intelligent data acquisition systems for fusion experiments using EPICS and FlexRIO technology, IEEE Trans. Nucl. Sci. 60 (2013) 3446–3453

work page 2013
[8]

Sanz, Modeling and integration of intelligent data acquisition systems into instrumentation systems for fusion devices (Ph.D

D. Sanz, Modeling and integration of intelligent data acquisition systems into instrumentation systems for fusion devices (Ph.D. dissertation), Univ. Politécnica de Madrid, Madrid, Spain, 2014

work page 2014

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [1]

Arredondo,M

I. Arredondo,M. Eguiraun, J. Jugo, D. Piso,M. del Campo, T. Poggi, et al., Adjustable ECR ion source control system, in: Real time conference 2014, Nara, Japan, 2014

work page 2014

[2] [2]

Arredondo, M

I. Arredondo, M. Eguiraun, D. Piso, M. del Campo, J. Feuchtwanger, G. Harper, et al., Sistema de Control de la fuente de iones ISHP, in: National Instruments case study, 2013

work page 2013

[3] [3]

Eguiraun, J

M. Eguiraun, J. Jugo, I. Arredondo, M. del Campo, J. Feuchtwanger, V. Etxebarria, et al., ISHN ion source control system. First steps toward an EPICS BASED ESS- Bilbao accelerator control system, IEEE Trans. Nucl. Sci. 60 (April (2)) (2013) 1280–1288

work page 2013

[4] [4]

M. Ruiz, J. Vega, R. Castro, D. Sanz, J.M. López, G. de Arcas, et al., ITER Fast Plant System Controller prototype based on PXIe platform, Fusion Eng. Des. 87 (12) (2012) 2030–2035

work page 2012

[5] [5]

Long, M.P

C.D. Long, M.P. Stockli, T.V. Gorlov, B. Han, S.N. Murray, T.R. Pennisi, Control system for the Spallation Neutron Source H-source test facility Allison scanner, Rev. Sci. Instrum. (2010) 02B722

work page 2010

[6] [6]

Payne, P.G

S.J. Payne, P.G. Barnes, G.M. Cross, A.H. Kershaw, N. Leach, A. Pertica, et al., Beam diagnostics at ISIS, 2008

work page 2008

[7] [7]

D. Sanz, M. Ruiz, R. Castro, J. Vega, J.M. Lopez, E. Barrera, et al., Implementation of intelligent data acquisition systems for fusion experiments using EPICS and FlexRIO technology, IEEE Trans. Nucl. Sci. 60 (2013) 3446–3453

work page 2013

[8] [8]

Sanz, Modeling and integration of intelligent data acquisition systems into instrumentation systems for fusion devices (Ph.D

D. Sanz, Modeling and integration of intelligent data acquisition systems into instrumentation systems for fusion devices (Ph.D. dissertation), Univ. Politécnica de Madrid, Madrid, Spain, 2014

work page 2014