{"id":"bae7b297-5878-46fa-b3d5-ba9103c59704","arxiv_id":"2501.18214","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"The NIRIO-EDS driver and RIO design methodology were applied for the first time to an operating ion source control system, letting EPICS IOCs run on Linux while keeping the original FPGA behavior.","lead":"This engineering paper reports moving the control software for the ESS Bilbao ion source (ISHP) from a LabVIEW-based system to Linux-based EPICS control servers using a previously developed driver called NIRIO-EDS. The authors show the system running and argue the approach makes RIO/FlexRIO FPGA devices easier to integrate into large accelerator control systems.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The claim that the ISHP FPGA behavior is unchanged after NIRIO-EDS adaptation is asserted but not demonstrated; a regression comparison is needed.","rationale":"The reader's weakest assumption is exactly the point I consider load-bearing: the paper's central result depends on the functional invariance of the FPGA logic after applying the NIRIO-EDS design rules. Section 3 describes the modification as renaming controls and indicators and adding base registers, which in LabVIEW FPGA should not alter the underlying dataflow logic if truly the only changes are to host interface terminals. However, the paper gives no artifact that would let a reviewer verify this: no before/after VI diff, no bitfile comparison, no regression procedure, and no quantitative comparison of operational behavior. The screenshots in Fig. 5 show a beam pulse and a GUI, but they do not establish that the new IOC reproduces the old behavior across the motor, DAQ, and trigger features. The qualifier 'most' in Section 4 also weakens the claim of full preservation. I found no internal contradiction in the design methodology itself; the concern is about missing evidence for an asserted equivalence. This matches the reader's conditional verdict, so I recommend no change to the verdict. The proposed test—a source-level diff plus a side-by-side acceptance run on the same hardware—would settle whether the invariance assumption holds or whether the migration introduced behavioral differences.","tokens_in":5052,"tokens_out":2995,"duration_ms":34157,"concrete_test":"Use LabVIEW's VI comparison/diff tool on the original and modified FPGA source for both the PXI-7852R and the cRIO device, and show that the only differences are the added NIRIO-EDS base-register block and the renamed/added I/O terminals, with all other logic nodes and wires unchanged. Then run a defined acceptance sequence on the same hardware under both the original LabVIEW RT IOC and the NIRIO-EDS Linux IOC: step motors through a fixed profile, acquire a synthetic or previously recorded ACCT-like pulse, and execute the RF trigger sequence; compare sampled waveforms, motor positions, and trigger timing. If the source diff is not limited to the stated changes, or if any measured output differs beyond expected jitter, the invariance claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4's central claim is that the NIRIO-EDS migration preserved data acquisition, motor control, and trigger sequencing because 'All of the code and the features that were initially programmed in the FPGAs remain the same as before and functioning properly.' The load-bearing assumption is Section 3's statement that adapting an existing FPGA design reduces to 'adding all the base registers required by the NIRIO-EDS driver' and 'changing the controls and indicators names in the LabVIEW code.' If adding registers or renaming endpoints changed FPGA resource usage, timing closure, or host-FPGA register/DMA behavior, the equivalence would fail. The paper provides no diff of the FPGA source before and after, no regression or acceptance test data, no comparison of acquired beam pulses, motor trajectories, or trigger timings between the original LabVIEW IOC and the new Linux IOC, and no PV list or record-type inventory proving coverage of the claimed features. Section 4 also says the driver 'supports most of the previous control features' and later says 'All of the code and the features ... remain the same as before,' and this tension is not resolved. The invariance claim is plausible because LabVIEW FPGA controls and indicators are host interface surfaces, but plausibility is not evidence; an unsupported equivalence is the soft spot of the paper.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":5255,"tokens_out":3335,"duration_ms":31706,"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":[{"comment":"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":"Section 3, paragraph 6"},{"comment":"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":"Section 4, first two paragraphs"},{"comment":"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":"Section 4 and Fig. 5"},{"comment":"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.","section":"Section 2, paragraph 3"}],"minor_comments":[{"comment":"The phrase 'Fig. 1shows' is missing a space; it should read 'Fig. 1 shows'.","section":"Section 2, paragraph 2"},{"comment":"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":"Section 3, paragraphs 4 and 6"},{"comment":"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":"Section 2, paragraph 3"},{"comment":"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.","section":"Section 4, Fig. 5"},{"comment":"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.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper fits the scope of physics.ins-det as an application/case-study contribution, but its central claim rests on an unverified invariance assumption and the results are entirely qualitative. I would encourage the editor to require the authors to either provide regression evidence or substantially weaken the claim of full functional preservation. The self-citation concentration (most references are the authors' own prior works) is not a reason for rejection by itself, but it increases the need for independent or quantitative confirmation."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nThe 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.\n\nThat 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.\n\nMy 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.","headline":"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.","tokens_in":5835,"tokens_out":1510,"would_cite":false,"duration_ms":18024,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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…","keywords":["EPICS","FPGA","PXI","RIO technology","FlexRIO","LabVIEW","ion source control","device support"],"falsifier":"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.","tokens_in":4820,"feed_emoji":"⚛️","tokens_out":11335,"duration_ms":100186,"temperature":0.7,"pith_summary":"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.","feed_headline":"Ion source control moves to EPICS Linux by renaming FPGA registers","feed_subtitle":"The FPGA logic stays untouched, so existing ion-source behavior carries into a full Linux EPICS environment.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines the previous operational ISHP ion-source control system and its EPICS-based behavior, the baseline the migration claims to preserve.","marker":"[3]"},{"why":"Documents the methodology's earlier use on fast plant system controller prototypes, establishing the approach the case study applies.","marker":"[4]"},{"why":"Provides the original NIRIO-EDS implementation for intelligent data acquisition systems, the device-support mechanism reused here.","marker":"[7]"},{"why":"Supplies the LabVIEW RIO/FlexRIO design rules and patterns that the migration follows when adding base registers and renaming registers.","marker":"[8]"}],"fun_headline_variants":["Rename FPGA registers, keep logic: ion source controls go Linux EPICS","Ion source EPICS: same FPGA code, new register names, no LabVIEW IOC","FPGA logic untouched, register names changed: EPICS bridge for ISHP","Drop LabVIEW IOC: NIRIO-EDS adopts ion source via register renaming"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Rename FPGA registers, keep logic: ion source controls go Linux EPICS","Ion source EPICS: same FPGA code, new register names, no LabVIEW IOC","FPGA logic untouched, register names changed: EPICS bridge for ISHP","Drop LabVIEW IOC: NIRIO-EDS adopts ion source via register renaming"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000259,"raw_usage":{"total_tokens":1625,"prompt_tokens":1025,"completion_tokens":600,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":641,"completion_tokens_details":{"reasoning_tokens":512}},"tokens_in":641,"tokens_out":600,"duration_ms":6200,"temperature":1.0,"reasoning_tokens":512,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T00:16:28.422011+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Eguiraun, J","cited_arxiv_id":null,"evidence_quote":"Defines the previous operational ISHP ion-source control system and its EPICS-based behavior, the baseline the migration claims to preserve."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents the methodology's earlier use on fast plant system controller prototypes, establishing the approach the case study applies."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the original NIRIO-EDS implementation for intelligent data acquisition systems, the device-support mechanism reused here."},{"cited_title":"Sanz, Modeling and integration of intelligent data acquisition systems into instrumentation systems for fusion devices (Ph.D","cited_arxiv_id":null,"evidence_quote":"Supplies the LabVIEW RIO/FlexRIO design rules and patterns that the migration follows when adding base registers and renaming registers."}],"review_version":1}