LabWindows/CVI Alternatives in 2026 (Free & Modern C Options)

LabWindows/CVI is NI's ANSI C development environment for test and measurement applications, combining a C compiler, instrument driver libraries, a UI builder, and analysis functions. It is the text-based counterpart to LabVIEW, and it has been the backbone of production test applications in aerospace, defence, and semiconductor for decades.

It is also in maintenance mode, carries a four-figure per-seat subscription, and increasingly struggles to find engineers who want to work in it. This post covers the realistic alternatives and, more usefully, how to migrate an application that has been running since 2009 without stopping production.

The actual problem with CVI in 2026

It is not that the tool is bad. Written well, a CVI application is fast, deterministic, and has run unattended for years.

The problems are structural:

• •Maintenance mode. Releases are infrequent. New instrument support and OS certification arrive late or not at all. A Windows upgrade becomes a risk event.
• •Hiring. The population of engineers who want to write ANSI C in a proprietary IDE is shrinking every year. New graduates arrive knowing Python.
• •Per-seat subscription on a tool that is no longer strategically invested in.
• •The code has outlived its author. This is the real one. The application works, nobody fully understands it, and every change is a risk.

That last point is what makes migration feel impossible, and it is also why the migration strategy below matters more than the tool choice.

What is actually in a CVI application

Open a typical one and the line count breaks down roughly like this:

The two largest layers are the two easiest to replace. That is the insight that makes migration tractable. The part that is genuinely hard, your calibration maths and your domain-specific algorithms, is a small minority of the code and can usually be kept as-is.

The alternatives

1. Python with pyVISA

Free, and the destination most teams end up at.

import pyvisa

rm = pyvisa.ResourceManager()
psu = rm.open_resource("TCPIP0::192.168.1.42::inst0::INSTR")
dmm = rm.open_resource("USB0::0x2A8D::0x1301::MY57200001::INSTR")

psu.write("VOLT 3.3"); psu.write("OUTP ON")
dmm.write("CONF:VOLT:DC 10,0.0001")
vout = float(dmm.query("READ?"))
psu.write("OUTP OFF")

assert 3.2 <= vout <= 3.4, f"VOUT {vout} out of limits"

Good for: the instrument and sequencing layers, which is most of the application. Hiring is easy, the ecosystem is enormous, and it runs in CI.

Gives up: hard determinism and the UI builder. Python on Windows is not a real-time environment, though for the vast majority of CVI applications it was never actually relying on that.

Keeping your C: compile your measurement algorithms as a DLL and call them with ctypes. Validated maths stays validated.

Verdict: the default recommendation. See the PyVISA tutorial.

2. TestFlow

Generates the instrument and sequencing layers rather than having you rewrite them. You describe the test in plain English, name the instruments, and it produces the automation and runs it, with the report as an output rather than a thing you code.

Good for: exactly the 60 to 75 percent of a CVI application that is mechanical. It does not care that the original was C.

Gives up: the custom algorithms, which stay yours, and any hard-determinism requirement.

Verdict: the fastest route through the tedious majority of the migration.

3. Plain C or C++ with NI-VISA or Keysight IO Libraries

Free VISA layer, your own compiler and IDE. Visual Studio, CMake, and a modern toolchain instead of the CVI IDE.

Good for: teams with real determinism requirements, teams with a lot of C they refuse to leave, and regulated environments where a language change triggers requalification.

Gives up: the UI builder and the analysis library, both of which you now source elsewhere. Qt or Dear ImGui for the UI.

Verdict: the conservative move. Keeps the language, drops the vendor lock. Often the right first step.

4. Qt for the UI layer

If the UI panels are what keeps you on CVI, Qt is the serious answer. Commercial and open-source licensing, C++ native, and cross-platform.

Good for: operator interfaces that need to look and behave properly on modern displays.

Gives up: nothing technical, but Qt has a learning curve and a licensing decision to make.

Verdict: pair it with Qt below for a complete non-NI C stack.

5. OpenTAP

Free and open source sequencer from the Keysight ecosystem. Replaces the sequencing layer specifically, with plugins for instruments and results listeners for output.

Good for: the 25 to 35 percent of your code that is sequencing, with a supported structure rather than hand-rolled state machines.

Gives up: the UI and the C. Plugins are C# first.

Verdict: strong if you are also re-evaluating TestStand, since they compete directly.

Comparison table

The migration strategy that works

Do not rewrite the application. Strangle it.

1. 1

   Freeze the old application. No new features in CVI from today. Bug fixes only. This alone stops the problem growing.

2. 2

   Extract the algorithms first. Identify the measurement maths that is genuinely yours, pull it into a standalone DLL with a clean C interface, and unit-test it against known inputs. Do this while the old app still runs, and have the old app call the new DLL. Now the valuable part is portable and proven.

3. 3

   Build the new path for one test. Pick the single simplest test in the sequence. Implement it in the new tool, calling the same DLL. Run both, same DUT, same day.

4. 4

   Compare outputs numerically, not visually. Export both to CSV and diff them. Agreement to the measurement's own resolution is the pass criterion.

5. 5

   Move tests in batches, keeping the old app as the reference until the last batch. Production keeps running on CVI throughout.

6. 6

   Retire the licence at renewal, not before. You want the old app available until the new one has produced a full quarter of clean results.

The failure mode to avoid is the big-bang rewrite. Every CVI migration that goes badly is one where the team tried to reproduce the entire application in one go, discovered an undocumented behaviour in month four, and had no reference to check against because the old machine had been repurposed.

Wrapping existing CVI code so it survives the migration

The single most useful technique. Your measurement algorithms are the part worth keeping, and they are already C.

In CVI, export the function:

__declspec(dllexport) double CalculateOffsetCorrection(
    double raw_reading, double temperature_c, double cal_slope)
{
    return (raw_reading - (temperature_c * cal_slope)) * CAL_FACTOR;
}

Build as a DLL rather than an executable. This is a project setting change, not a code change.

From Python:

import ctypes

lib = ctypes.CDLL("./calibration.dll")
lib.CalculateOffsetCorrection.argtypes = [ctypes.c_double] * 3
lib.CalculateOffsetCorrection.restype = ctypes.c_double

corrected = lib.CalculateOffsetCorrection(raw, temp_c, slope)

Two consequences worth being explicit about. First, the validated maths stays byte-identical, so no requalification argument applies to it. Second, you can now unit-test it from Python against known inputs, which is very often the first time that code has ever had tests.

Do this before touching anything else. It converts the scary part of the migration into a solved problem and makes every later step lower risk.

What to do about the UI panels

Sort the panels into three buckets and handle each differently.

• •Diagnostic panels nobody uses in production. Delete. Most CVI applications have several.
• •The run panel: start, stop, pass/fail lamp, progress. Rebuild in a day with PyQt or a simple web page. This is the only one most applications genuinely need.
• •Instrument replica panels with dozens of controls. These are expensive to rebuild and usually exist because CVI made them cheap. Ask whether anyone has used one in the last year before rebuilding it.

The realistic outcome is that a 25-panel application needs two panels in the new stack.

Replacing the CVI instrument drivers

The other thing CVI gave you was a large library of instrument drivers, and losing them feels like losing capability. In practice most of those drivers are thin wrappers over SCPI strings you can send directly.

A CVI driver call like this:

Agilent34401_ConfigureMeasurement(handle, AGILENT34401_VAL_DC_VOLTS, 10.0, 0.0001);
Agilent34401_Read(handle, 10000, &reading);

Is this over pyVISA:

dmm.write("CONF:VOLT:DC 10,0.0001")
reading = float(dmm.query("READ?"))

The driver was saving you a lookup in the programming manual, not solving a hard problem. For the handful of genuinely complex instruments (a VNA calibration sequence, a spectrum analyser sweep setup) the vendor usually ships a Python package now, and where they do not, the SCPI command cheat sheet covers the common classes.

Two cases where the CVI driver is doing real work and deserves care: instruments with binary block transfers (waveform captures, trace data), and instruments with awkward status-byte handshaking. Both are solvable, both take an afternoon each, and both should be on the migration inventory rather than discovered late.

Deciding what "keep the C" actually means

Three different things get called "keeping the C", and they have very different costs.

The first row is the one that de-risks everything else, which is why it is step 2 in the migration above and not step 5.

What CVI still does better

Worth being straight about, because the decision goes wrong in both directions.

• •Determinism. Compiled C with no garbage collector and no interpreter. If a measurement loop has a hard timing budget in the low milliseconds, Python is the wrong tool and CVI is not.
• •The UI builder. Drag a control, get a callback. Building an equivalent panel in PyQt is more work, and anyone who says otherwise has not done it recently.
• •The instrument driver catalogue. Broad, and for the awkward instruments above, genuinely useful.
• •It already works. A CVI application that has run production for a decade carries a decade of undocumented fixes. That is real value and rewriting discards it.

The case for leaving is not that CVI is bad. It is that the hiring pool is shrinking, the licence stacks on top of the rest of the NI bill, and the application is usually one retirement away from being unmaintainable.

Common mistakes

• •The big-bang rewrite. Covered above, and it is the single most common way these projects fail.
• •Rewriting the measurement maths. Wrap it, do not port it. Rewriting invites a requalification argument you do not need to have.
• •Rebuilding every panel. Sort them into the three buckets first. A 25-panel application usually needs two.
• •Repurposing the old machine early. Keep it until the new path has produced a full quarter of clean results.
• •Comparing outputs by eye. Export both to CSV and diff numerically. Agreement to the measurement's own resolution is the criterion.
• •Choosing Python for a hard real-time loop. If the timing budget is genuinely low milliseconds, stay compiled. See HIL testing software compared for where that line sits.

Related reading

• •LabWindows/CVI explained, the product overview
• •LabVIEW alternatives, the graphical half of the NI stack
• •NI TestStand alternatives, if sequencing is the layer you are replacing
• •PyVISA tutorial, the free instrument-control route
• •Instrument control with VISA and SCPI, the protocol layer underneath all of this
• •SCPI command cheat sheet, the commands the old drivers were wrapping
• •NI software licensing costs, the full stack priced line by line
• •LabVIEW to Python migration, the same move from the graphical side
• •Test sequencer comparison, if the sequence is the part you are keeping
• •HIL testing software compared, where determinism is genuinely required
• •Python instrument control libraries compared, picking the replacement stack
• •Free instrument control software, the zero-cost options in one place
• •LabVIEW vs Python, the language decision stated plainly
• •Automated test report generation, the output the old app produced