LABIIUM: AI-Enhanced Zero-configuration Measurement Automation System

Danial Chitnis; Emmanuel A. Olowe

REVIEW 4 major objections 7 minor 18 references

LABIIUM: AI-Enhanced Zero-configuration Measurement Automation System

T0 review · 4 major / 7 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read Current large language models can generate and execute code for a routine uniform instrument sweep, but they cannot turn a described adaptive sampling algorithm into working measurement code that competes with an expert gradient-weighted…

desk verdict Useful LAMB hardware and a plausible negative LLM result, but the evidence is thin and the conclusion overclaims. read the letter →

arxiv 2412.16172 v2 pith:TSU7IAIB submitted 2024-12-07 cs.AI cs.CLcs.HCcs.SE

Emmanuel A. Olowe , Danial Chitnis This is my paper · ORCID

classification cs.AIcs.CLcs.HCcs.SE

keywords largelanguagemodelslaboratoryautomationzero-configurationmeasurementSCPIinstrumentsadaptivesamplingGWASStransfercurvecharacterizationtooluse

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 presents LABIIUM, a zero-configuration laboratory automation system in which a Raspberry Pi-based hardware bridge (LAMB) lets users control measurement instruments through Python and VS Code, and an AI chat assistant powered by large language models generates the control code. To test the system, the authors measured the transfer curves of a two-transistor inverting amplifier with a current-source load, sweeping the input and bias voltages while a digital multimeter recorded the output. They compared three LLMs (Claude Sonnet 3.5, Gemini Pro 1.5, GPT-4o) under three prompt scenarios against two baselines: a 10,000-point uniform sweep and a 100-point Gradient-Weighted Adaptive Stochastic Sampling (GWASS) expert method. The paper's central claim is that the LLMs successfully produced code for the basic uniform sweep, but none implemented a competing adaptive sampling strategy, even when GWASS was described in full.

What carries the argument

The load-bearing objects are the LAMB (Lab-Automation-Measurement Bridge), a Raspberry Pi4 running a Rust-implemented VISA layer that controls instruments over USBTMC and accepts SCPI commands through a server, and the LABIIUM Chat layer that lets an LLM call instrument functions and see execution output. The evaluation against which the claims are measured is the GWASS (Gradient-Weighted Adaptive Stochastic Sampling) baseline: it first takes a coarse sample, estimates the local gradient across the parameter space, and then allocates the remaining points probabilistically to high-gradient regions. The test circuit is a two-transistor inverting amplifier with a current-source load, whose transfer curve has a steep transition that flattens and shifts as the bias voltage changes. The comparison set is a 10,000-point uniform sweep, a 100-point uniform sweep, the 100-point GWASS expert solution, and the 100-point LLM-generated attempts under the three prompt conditions.

What would settle it

Re-run the three prompt scenarios on the same two-transistor amplifier rig, log every generated script and its execution output, and compute the fraction of the 100 sampling points that fall in the steep transition band; if any model reliably reproduces GWASS-like placement, or if the published graphs require human code repairs to reproduce, the claim of a universal inability to implement adaptive sampling would be overturned.

Watch

Extended reading notes

Core claim

The paper sets out to show that a zero-configuration instrument bridge plus an LLM assistant can produce working measurement code, and that the boundary of current LLM capability lies at adaptive sampling. On the paper's evidence, all three tested models completed the basic uniform sweep—the code ran and produced a transfer curve matching the 100-point linear reference—but every adaptive-sampling attempt remained essentially uniform. In Experiment 1, asking for an efficient sweep produced a uniform sweep. In Experiment 2, asking the model to sample regions with highest rate of change produced no change in sampling. In Experiment 3, providing the full GWASS description made results worse: outputs stayed largely uniform, sometimes delivered the wrong number of points, and one model failed entirely. The only measurement that concentrated its 100 samples at the steep transition was the expert-written GWASS baseline.

Load-bearing premise

The evaluation assumes the printed curves came from code the LLMs generated and executed without undocumented human repair or selection among attempts, since the paper reports no prompts, code listings, execution logs, or quantitative success metric.

Editorial extensions

If this is right

LABIIUM removes the driver and configuration layer from routine measurement: any Python/VS Code user can sweep an instrument through a standardized SCPI endpoint without writing VISA code.
The GWASS comparison quantifies what adaptive sampling buys: 100 targeted points capture the same transfer-curve structure that a 10,000-point uniform sweep provides, so the same accuracy can be had at a fraction of the measurement time.
A full textual description of an algorithm is not sufficient for current LLMs to implement it correctly in this domain; future systems will need specialized training, better prompts, or external state-management tools.
The same three-prompt, three-model setup can serve as a reusable benchmark for measuring progress in LLM-based measurement automation.

Reading between the lines

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

The failure pattern suggests the bottleneck is not language understanding but the absence of a closed loop: a human expert writes adaptive code because they see partial curves and react, while the LLM wrote a fixed script from a static description.
A direct test of that hypothesis would give the LLM a running summary of measured points and the option to revise its plan after each batch; if adaptive placement then emerges, the gap is an architectural one rather than a fundamental LLM limit.
If this gap persists across models and prompts, the short-term practical division of labor is clear: LLM agents will take over high-volume routine sweeps, while adaptive measurement strategy remains human expertise until tool-use agents learn to act on measurement history.
The paper's own conclusion says LABIIUM with expert GWASS achieved measurement efficiencies comparable to a human expert; that is a statement about the platform, not about the LLMs, and separating those two claims would be a useful clarification for the field.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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

Short version: the LAMB hardware is real engineering and the negative LLM result is plausible, but the paper as written does not support its own conclusions. The evidence is visual, the artifacts are missing, and the conclusion in Section V contradicts the abstract.

What is actually new: a Raspberry-Pi-based VISA bridge written in Rust, with a server that speaks SCPI over USBTMC and integrates with VSCode and Python. That is useful for labs that want to avoid proprietary drivers. The evaluation matrix — three LLMs, three prompt scenarios, one expert baseline — is a reasonable way to probe whether LLMs can implement adaptive sampling. The visual result, that all three LLMs stick to uniform sweeps even when told about GWASS, is a credible negative result.

Soft spots: the negative result rests entirely on Figure 4 and Table I. There are no prompts, no generated code, no execution logs, no raw data, and no quantitative measures like reconstruction error, sample placement, or time-to-measurement. Without those, the reader cannot tell whether the curves came from a single unedited run or from selection and repair. Table I says Experiment 3 results 'massively decline in performance' with 'one model failing entirely,' while the Figure 4 caption says those attempts were 'slightly improved.' That is an internal inconsistency. And Section V claims LABIIUM 'achieved measurement efficiencies comparable to the human-expert baseline,' which contradicts the abstract's finding that LLMs could not compete with GWASS. The conclusion seems to credit the expert implementation to LABIIUM, which is confusing.

The paper also overreaches when it generalizes from one simple two-transistor circuit to a claim about LLM 'capacity for dynamic decision-making.' The software-side productivity claims (zero configuration, faster prototyping) are asserted, not measured.

Bottom line: a decent systems note with a plausible but unproven empirical claim. It deserves a serious referee only if the authors are required to supply the prompt-code-log trail and fix the internal inconsistencies. Otherwise a desk reject with an invitation to resubmit would be defensible. I would not cite it yet, but it is worth a reading group discussion about the failure mode.

Referee Report

4 major / 7 minor

Summary. The paper introduces LABIIUM, a measurement-automation system built around Raspberry Pi-based Lab-Automation-Measurement Bridges (LAMBs), a custom Rust VISA/USBTMC implementation, and an LLM-powered chat assistant that generates and executes instrument-control code. The authors evaluate three LLMs (GPT-4o, Claude Sonnet 3.5, Gemini Pro 1.5) under three prompt scenarios, asking each model to generate code that sweeps the transfer curve of a two-transistor inverter. They compare the resulting curves visually against a 10,000-point uniform sweep and an expert-written Gradient-Weighted Adaptive Stochastic Sampling (GWASS) baseline. The paper's central claim is that LLMs can produce basic uniform sweeps but cannot implement adaptive sampling strategies competitive with GWASS. Section V goes further, claiming that LABIIUM achieved measurement efficiencies comparable to the human-expert baseline, a statement that appears to contradict the negative LLM result described in the abstract and in Section III.

Significance. If fully supported, the central finding would be a useful, falsifiable negative result for the AI-for-science community: current LLMs can automate straightforward instrument-control code but cannot yet design measurement strategies that adapt to the shape of the measured response. The LABIIUM architecture, especially the Rust-based VISA implementation and the context-reduction strategy for feeding Python libraries to LLMs, is a practical engineering contribution. The experimental comparison is genuinely empirical and does not fit parameters to force a conclusion, which is a strength. However, the evidence as presented is not yet at journal standard: the negative result rests entirely on visual inspection of Figure 4, no quantitative metrics or statistical tests are provided, and the prompts, generated code, and execution logs are absent. The paper also contains an internal inconsistency between Table I and the Figure 4 caption, and the conclusion conflates the expert-written GWASS code with LLM-generated code.

major comments (4)

[Section III, Figure 4] The central claim that LLM-generated sweeps remain uniform and fail to implement adaptive sampling is supported only by visual inspection of Figure 4. No quantitative metrics are reported: there are no counts of samples placed in high-gradient regions, no reconstruction error relative to the 10,000-point reference, no measurement-time comparisons, and no statistical analysis across repeated runs. Because the paper's headline conclusion concerns 'efficiency' and 'adaptive' behavior, which are quantitative concepts, this evidence is insufficient as it stands. Please add quantitative metrics and, where feasible, repeated-run statistics or error bars.
[Section II-D and Section III] The prompts are described only at a high level, and the generated code, execution logs, raw measurement data, and per-subplot model attribution are not included. Without these artifacts, a reader cannot verify that each plotted curve in Figure 4 is the single unedited output of one code-generation-and-execution pass rather than a hand-repaired or selected attempt. This is load-bearing because Section IV generalizes from these plots to a broad claim about LLMs' 'limited capacity for dynamic decision-making.' Please include the exact prompts (including the claimed full description of GWASS in Experiment 3), representative generated code for each model and experiment, and execution logs.
[Table I and Figure 4 caption] The results are internally inconsistent. Table I states that Experiment 3 outputs 'massively decline in performance' and that 'one model failing entirely,' while the Figure 4 caption describes Experiment 3 as 'slightly improved' and Section III states that these attempts 'occasionally place a few points more strategically.' These statements cannot all be true of the same data, and they lead to different conclusions about whether providing the full GWASS description helped or hurt. Please reconcile these statements and clarify what 'failing entirely' means (e.g., no output, runtime error, or unusable result).
[Section V (Conclusion)] The conclusion states that 'LABIIUM, leveraging AI and the GWASS method, achieved measurement efficiencies comparable to the human-expert baseline,' but the experiments show that the expert GWASS baseline was a hand-written implementation and that the LLM-generated adaptive sweeps did not match it. This conflates the LABIIUM platform with the expert implementation and contradicts the abstract's negative finding. Please rephrase the conclusion to state explicitly that only the expert-written GWASS code achieved the efficiency, while the LLM-generated code did not.

minor comments (7)

[Section II-B] There is a typo: 'Y AML configurations' should be 'YAML configurations,' and 'rust library' should be capitalized consistently.
[Section II-C] The text contains a duplicated word: 'The DMM then then measured Vout.' Also, 'For each value of Vbias ... AI-generated would then sample' is grammatically incomplete.
[Figure 4] Subplots (d) through (l) are not labeled with the corresponding LLM, so the reader cannot tell which model produced which result. Please add a legend or a table mapping models to subplots.
[Throughout] The method is spelled inconsistently as 'GWASS' and 'GW ASS'; please choose one spelling and use it consistently.
[Section II-C] The number of points used by the expert GWASS baseline is not stated in the text; Figure 4 suggests 100 points, but this should be explicit, along with the specific Vbias values used.
[Section I and Section II-A] The 'zero-configuration' claim is supported only by an architecture description. No setup-time or usability comparison with LabVIEW or MATLAB is reported, so the productivity benefit is not directly measured.
[References] Several references have formatting inconsistencies, such as incomplete author initials and inconsistent spacing; these should be cleaned up before publication.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the LLM-vs-GWASS comparison is empirical and self-contained; missing artifacts and internal inconsistencies affect reproducibility, not circularity.

full rationale

The paper's central claim is an experimental result: LLM-generated code produced uniform sweeps and did not match the expert GWASS baseline. This claim is not derived from a fitted parameter or from a theorem imported from the authors' prior work. The GWASS baseline is described in Section II-E and used as a benchmark; although it was implemented by the authors, it is not cited as an external uniqueness result and it does not define the outcome variable of the evaluation. The LLM outputs are independently generated under the three prompt scenarios in Section II-D, and the failure is presented as directly observed behavior in Figure 4 and Table I. No equation in the paper reduces the conclusion to its inputs by construction, and no fitted quantity is renamed as a prediction. The absence of prompts, generated code, execution logs, and quantitative error metrics, and the tension between the abstract's negative result and Section V's 'comparable to the human-expert baseline' statement, are reproducibility and internal-consistency concerns, not circularity. Under the specified definition of circularity, no step warrants a nonzero score.

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

The central claims rest on assumptions about the execution environment and the validity of qualitative evaluation. The LAMB is a hardware system, not a newly postulated physical entity, so no invented entities are listed.

assumptions (3)

domain assumption The LLM-generated code was executed via LABIIUM without human correction or cherry-picking of successful runs.
No logs or code listings are provided, so the attribution of the graphs to LLM capability rests on this premise. See Sections II-D and III.
domain assumption Visual inspection of transfer curves is sufficient to compare sampling efficiency.
The results section compares methods qualitatively through Figure 4 and never reports a quantitative error metric. See Section III.
domain assumption The calibrated instruments respond correctly to the SCPI commands with negligible drift across the hours-long measurement.
The reported standard deviation of 8.58e-7 for the DMM supports low noise, but long-term stability of the PSU sweeps is assumed. See Section II-C.

how reviews work

0 comments

Cite this review

Pith. "Pith review of LABIIUM: AI-Enhanced Zero-configuration Measurement Automation System." pith.science (2026). https://pith.science/paper/TSU7IAIB

@misc{pith2026241216172,
  author       = {Pith},
  title        = {Pith review of: LABIIUM: AI-Enhanced Zero-configuration Measurement Automation System},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TSU7IAIB}},
  note         = {Machine review of arXiv:2412.16172}
}

read the original abstract

The complexity of laboratory environments requires solutions that simplify instrument interaction and enhance measurement automation. Traditional tools often require configuration, software, and programming skills, creating barriers to productivity. Previous approaches, including dedicated software suites and custom scripts, frequently fall short in providing user-friendly solutions that align with programming practices. We present LABIIUM, an AI-enhanced, zero-configuration measurement automation system designed to streamline experimental workflows and improve user productivity. LABIIUM integrates an AI assistant powered by Large Language Models (LLMs) to generate code. LABIIUM's Lab-Automation-Measurement Bridges (LAMBs) enable seamless instrument connectivity using standard tools such as VSCode and Python, eliminating setup overhead. To demonstrate its capabilities, we conducted experiments involving the measurement of the parametric transfer curve of a simple two-transistor inverting amplifier with a current source load. The AI assistant was evaluated using different prompt scenarios and compared with multiple models, including Claude Sonnet 3.5, Gemini Pro 1.5, and GPT-4o. An expert solution implementing the Gradient-Weighted Adaptive Stochastic Sampling (GWASS) method was used as a baseline. The solutions generated by the AI assistant were compared with the expert solution and a uniform linear sweep baseline with 10,000 points. The graph results show that the LLMs were able to successfully complete the most basic uniform sweep, but LLMs were unable to develop adaptive sweeping algorithms to compete with GWASS. The evaluation underscores LABIIUM's ability to enhance laboratory productivity and support digital transformation in research and industry, and emphasizes the future work required to improve LLM performance in Electronic Measurement Science Tasks.

Figures

Figures reproduced from arXiv: 2412.16172 by the authors.

**Figure 1.** Architecture of the Lab-Automation Measurement Bridge (LAMB). The Raspberry Pi4 serves as the standardized hardware platform, running the [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗

**Figure 2.** Schematic diagram of the two-transistor inverting amplifier with a [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Gradient-Weighted Adaptive Stochastic Sampling Algorithm Process [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: (a), (b) represent linear sweeps of differing resolution, with (a) employing 10,000 points and (b) using only 100 points. (c) illustrates the GWASS [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

18 extracted references · 16 canonical work pages

[1]

Advantages of early adoption of LabVIEW as industry-standard software in academia,

A. ˇSkamo and D. Joki ´c, “Advantages of early adoption of LabVIEW as industry-standard software in academia,” in 2023 12th Mediterranean Conference on Embedded Computing (MECO) . IEEE, 6 2023, pp. 1–4

work page 2023
[2]

Ask or tell: An empirical study on modeling challenges from LabVIEW community,

X. Zhao, G. Rai, and S. Popoola, “Ask or tell: An empirical study on modeling challenges from LabVIEW community,” Journal of Computer Languages, vol. 80, p. 101284, 8 2024

work page 2024
[3]

LabVIEW,

J. Kodosky, “LabVIEW,” Proceedings of the ACM on Programming Languages, vol. 4, no. HOPL, pp. 1–54, 6 2020

work page 2020
[4]

The MathWorks, “MATLAB,” Natick, Massachusetts, 2024

I. The MathWorks, “MATLAB,” Natick, Massachusetts, 2024

work page 2024
[5]

Comparative study about data speed acquisition and recording in a MySQL database of LabVIEW, MATLAB and Python programming languages,

L. S. Csokmai, C. M. Novac, and O. C. e. a. Novac, “Comparative study about data speed acquisition and recording in a MySQL database of LabVIEW, MATLAB and Python programming languages,” in 2021 13th International Conference on Electronics, Computers and Artificial Intelligence (ECAI). IEEE, 7 2021, pp. 1–4

work page 2021
[6]

Performance comparison of instrument automation pipelines using different programming languages,

A. Kumar and M. Goswami, “Performance comparison of instrument automation pipelines using different programming languages,” Scientific Reports, vol. 13, no. 1, p. 18579, 10 2023

work page 2023
[7]

Development of Python- Based Applications for Virtual Instrument Control Using PyQt5, PyVISA, and SCPI Protocol,

A. S. Rao, D. Sai, and A. T. e. a. Mahajan, “Development of Python- Based Applications for Virtual Instrument Control Using PyQt5, PyVISA, and SCPI Protocol,” in 2024 Second International Conference on Emerg- ing Trends in Information Technology and Engineering (ICETITE) . IEEE, 2 2024, pp. 1–7

work page 2024
[8]

SwiftVISA: Controlling Instrumentation with a Swift-based Implementation of the VISA Communication Protocol,

C. Barnes, L. Henke, L. Henke, I. Krukov, and O. Hildreth, “SwiftVISA: Controlling Instrumentation with a Swift-based Implementation of the VISA Communication Protocol,” Journal of Open Source Software, vol. 8, no. 83, p. 4752, 3 2023

work page 2023

Show all 18 references

[9]

Language models are few- shot learners,

T. Brown, B. Mann, and N. e. a. Ryder, “Language models are few- shot learners,” in Advances in Neural Information Processing Systems , H. Larochelle, M. Ranzato, R. Hadsell, M. Balcan, and H. Lin, Eds., vol. 33. Curran Associates, Inc., 2020, pp. 1877–1901

2020
[10]

Executable code actions elicit better LLM agents,

X. Wang, Y . Chen, and L. Y . et al, “Executable code actions elicit better LLM agents,” in ICLR 2024 Workshop on Large Language Model (LLM) Agents , 2024. [Online]. Available: https: //openreview.net/forum?id=8oJyuXfrPv

2024
[11]

From text to test: AI-generated control software for materials science instruments,

D. F ´ebba, K. Egbo, W. A. Callahan, and A. Zakutayev, “From text to test: AI-generated control software for materials science instruments,” Digital Discovery, 2024

2024
[12]

Toolformer: Language models can teach themselves to use tools,

T. Schick, J. Dwivedi-Yu, and R. D. et al, “Toolformer: Language models can teach themselves to use tools,” in Thirty-seventh Conference on Neural Information Processing Systems , 2023

2023
[13]

Gorilla: Large language model connected with massive apis,

S. G. Patil, T. Zhang, X. Wang, and J. E. Gonzalez, “Gorilla: Large language model connected with massive apis,” arXiv preprint arXiv:2305.15334, 2023

2023 arXiv
[14]

LLM With Tools: A Survey,

Z. Shen, “LLM With Tools: A Survey,” arXiv preprint arXiv:2409.18807, 9 2024

2024 arXiv
[15]

Virtual Instrument Software Architecture Specifica- tion,

I. V . I. Foundation, “Virtual Instrument Software Architecture Specifica- tion,” 2024

2024
[16]

Standard Commands for Programmable Instruments (SCPI), V olume 1: Syntax and Style,

SCPI Consortium, “Standard Commands for Programmable Instruments (SCPI), V olume 1: Syntax and Style,” San Diego, CA, USA, 5 1999

1999
[17]

Lost in the Middle: How Language Models Use Long Contexts,

N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang, “Lost in the Middle: How Language Models Use Long Contexts,” Transactions of the Association for Computational Linguistics, vol. 12, pp. 157–173, 2 2024

2024
[18]

Why does the effective context length of LLMs fall short?

C. An, J. Zhang, and M. Z. et al, “Why does the effective context length of LLMs fall short?” in The Thirteenth International Conference on Learning Representations , 2025

2025

Pith tools

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

[1] [1]

Advantages of early adoption of LabVIEW as industry-standard software in academia,

A. ˇSkamo and D. Joki ´c, “Advantages of early adoption of LabVIEW as industry-standard software in academia,” in 2023 12th Mediterranean Conference on Embedded Computing (MECO) . IEEE, 6 2023, pp. 1–4

work page 2023

[2] [2]

Ask or tell: An empirical study on modeling challenges from LabVIEW community,

X. Zhao, G. Rai, and S. Popoola, “Ask or tell: An empirical study on modeling challenges from LabVIEW community,” Journal of Computer Languages, vol. 80, p. 101284, 8 2024

work page 2024

[3] [3]

LabVIEW,

J. Kodosky, “LabVIEW,” Proceedings of the ACM on Programming Languages, vol. 4, no. HOPL, pp. 1–54, 6 2020

work page 2020

[4] [4]

The MathWorks, “MATLAB,” Natick, Massachusetts, 2024

I. The MathWorks, “MATLAB,” Natick, Massachusetts, 2024

work page 2024

[5] [5]

Comparative study about data speed acquisition and recording in a MySQL database of LabVIEW, MATLAB and Python programming languages,

L. S. Csokmai, C. M. Novac, and O. C. e. a. Novac, “Comparative study about data speed acquisition and recording in a MySQL database of LabVIEW, MATLAB and Python programming languages,” in 2021 13th International Conference on Electronics, Computers and Artificial Intelligence (ECAI). IEEE, 7 2021, pp. 1–4

work page 2021

[6] [6]

Performance comparison of instrument automation pipelines using different programming languages,

A. Kumar and M. Goswami, “Performance comparison of instrument automation pipelines using different programming languages,” Scientific Reports, vol. 13, no. 1, p. 18579, 10 2023

work page 2023

[7] [7]

Development of Python- Based Applications for Virtual Instrument Control Using PyQt5, PyVISA, and SCPI Protocol,

A. S. Rao, D. Sai, and A. T. e. a. Mahajan, “Development of Python- Based Applications for Virtual Instrument Control Using PyQt5, PyVISA, and SCPI Protocol,” in 2024 Second International Conference on Emerg- ing Trends in Information Technology and Engineering (ICETITE) . IEEE, 2 2024, pp. 1–7

work page 2024

[8] [8]

SwiftVISA: Controlling Instrumentation with a Swift-based Implementation of the VISA Communication Protocol,

C. Barnes, L. Henke, L. Henke, I. Krukov, and O. Hildreth, “SwiftVISA: Controlling Instrumentation with a Swift-based Implementation of the VISA Communication Protocol,” Journal of Open Source Software, vol. 8, no. 83, p. 4752, 3 2023

work page 2023