How to Write a LabVIEW Instrument Driver: Steps, Layers and Common Mistakes

A LabVIEW instrument driver is a set of VIs that lets your application control a piece of hardware through simple calls such as Initialize, Configure, Measure and Close, without knowing the device’s command syntax or bus. To write one: check whether a good driver already exists, learn the device’s command set, choose the transport (usually VISA), build small command and parsing VIs, wrap them in a clean API with error handling, and test it against the real instrument.

Drivers are where most LabVIEW projects meet the physical world, and where many of them go wrong. For background on the platform itself, see What Is LabVIEW?

Step 1: Check for an existing driver first

Writing a driver from scratch is often unnecessary. Before starting, look in three places:

• NI’s Instrument Driver Network (IDNet), which hosts LabVIEW drivers for thousands of instruments, many built to NI’s plug-and-play structure.
• The instrument maker’s website, which may offer LabVIEW VIs, a .NET assembly or a C DLL you can call from LabVIEW.
• Your own past projects, where a driver for the same family of devices may already exist.

Treat any existing driver as a starting point, not a finished product. Open it, check its error handling and timeouts, and confirm it supports the functions you need before you build on it.

Step 2: Learn the instrument and its command set

Read the programming manual, not just the user manual. You need to know:

• The physical interface and settings: serial baud rate, parity and stop bits; GPIB address; IP address and port.
• How messages end: most text-based instruments terminate with a line feed (\n), some with carriage return plus line feed.
• The command syntax. Many bench instruments follow SCPI, so commands such as *IDN?, *RST and SYST:ERR? work the same way across brands.
• Response formats, units and how the device reports errors.
• How long operations take, so you can set realistic timeouts.

Step 3: Choose the transport

Interface	LabVIEW tool	Typical devices	Notes
RS-232 / RS-485 serial	VISA (Configure Serial Port, Write, Read)	Controllers, scales, older instruments	Match baud, parity, stop bits and termination exactly
GPIB	VISA	Legacy and high-end bench instruments	Same VISA calls as serial; address set on the instrument
USB (USBTMC)	VISA	Modern bench instruments	Appears as a VISA resource; no serial settings needed
Ethernet (LXI, raw socket)	VISA or TCP/UDP functions	Network instruments, power supplies	VISA keeps the code bus-independent; raw TCP for custom protocols
Modbus RTU / TCP	LabVIEW Modbus library	PLCs, drives, meters	Register maps instead of text commands
NI DAQ, CompactRIO, PXI	DAQmx, RIO drivers	NI measurement hardware	Usually configured, not written; wrap tasks in your own API

Prefer VISA whenever the instrument supports it. The same Write and Read calls work over serial, GPIB, USB and Ethernet, so moving an instrument to a different bus only changes the resource name.

Step 4: Design the driver in layers

Layer	Responsibility	Example VIs
Transport	Open the session, write bytes, read bytes, close	Open Session, Write, Read, Close
Command and parsing	Build command strings, parse replies into numbers, check for device errors	Format Command, Parse Number, Check Error Queue
Driver API	Task-level functions an application developer actually uses	Initialize, Configure DC Voltage, Read Measurement, Reset, Close
Hardware abstraction (optional)	A generic interface so different models can be swapped	DMM.lvclass with child classes per model

Keeping these layers separate means a protocol change stays in the transport, a firmware change stays in parsing, and the application above never notices.

Step 5: Build the core VIs

Every robust driver has the same handful of VIs at its center:

• Initialize opens the session, sets timeouts and termination, optionally resets the device, and verifies it with an identity query.
• Configure VIs set ranges, modes and triggers using typed inputs (enums and numbers), not free-text strings.
• Action and Measure VIs trigger or read results and return values in engineering units.
• Error Query reads the instrument’s own error queue and converts entries into LabVIEW errors.
• Reset and Close return the device to a known state and release the session.

Worked example: reading a DC voltage

Here is the flow for a SCPI digital multimeter on USB:

1. Initialize: VISA Open on the USB resource, set a 5 s timeout, enable the line-feed termination character, write *IDN? and confirm the model in the reply.
2. Configure: write CONF:VOLT:DC 10 to select the 10 V range.
3. Measure: write READ? and read the reply, for example +1.23450E+00.
4. Parse: convert the string with Fract/Exp String To Number to get 1.2345 V, and raise an error if the conversion fails.
5. Check errors: write SYST:ERR?; a reply beginning with 0 means no error.
6. Close: VISA Close, even if an earlier step returned an error.

The application developer sees only Initialize, Configure DC Voltage, Read Measurement and Close. The command strings stay inside the driver.

Step 6: Handle errors and timeouts properly

• Wire the error cluster through every VI so a failure stops the sequence cleanly instead of cascading.
• Set timeouts from the instrument’s real response times, with margin. A timeout that is too short causes random failures; one that is too long freezes the operator interface.
• Query the instrument’s error queue after configuration steps; many devices silently ignore bad commands otherwise.
• Map common device errors to clear messages an operator can act on.
• Always close sessions, including in error paths, so a rerun does not find the port still in use.

Step 7: Test, document and package

• Test every VI against the real instrument, including deliberate faults: unplugged cable, wrong address, out-of-range settings.
• Build a simple test VI or unit tests that exercise the API, and rerun them after any change.
• Document each VI: what it does, units, valid ranges and errors returned. Use consistent icons and connector panes.
• Package the driver as a LabVIEW library or class with a clear public API, keep it in source control, and version it.

Common LabVIEW driver mistakes

Mistake	What happens	Better approach
Command strings scattered through the application	Every model change means hunting through the whole codebase	Keep commands inside the driver; expose task-level VIs
Fixed waits instead of proper reads	Slow tests, and failures when the instrument is busier than usual	Use termination characters, status polling or operation-complete queries
Ignoring the instrument’s error queue	Bad settings go unnoticed and measurements are wrong	Query and report device errors after configuration
String inputs for settings	Typos reach the instrument at runtime	Use enums and validated numeric inputs
No abstraction for interchangeable instruments	Replacing an obsolete model forces an application rewrite	Add a hardware abstraction layer for instrument types likely to change

Good drivers are also what makes a system supportable years later, when an instrument is discontinued. See LabVIEW support options for what keeping an older system running involves.

Frequently asked questions

Related articles

• What Is LabVIEW? Functionality, Architecture and Applications
• LabVIEW Support Options: NI, Community, Integrator or In-House
• How to Vet LabVIEW Expertise: CLAD vs CLD vs CLA, Questions and Red Flags
• Automated Test Software: Test Executives, TestStand, LabVIEW and Python
• Data Acquisition Software: Ready-to-Run, LabVIEW, Python or Custom?