Building a LabVIEW VISA Instrument Driver for NI Certification

A VISA-accessible measurement and signal-generation instrument needs two separate pieces of work. The first is firmware on the instrument that parses SCPI-style ASCII commands arriving on Ethernet, USB, or serial. The second is a LabVIEW instrument driver on the host that builds those command strings, sends them through VISA, and parses the replies. NI certification covers only the second piece. NI judges it against the Instrument Driver Guidelines and the 2014 revision of the instrument driver templates.

Common first attempts at a VISA driver and why they stall

Most new driver projects lose time on one of the approaches below. Each one fails for a specific reason.

Approach tried	Why it fails	What to do instead
Asking NI for help with the on-instrument SCPI parser	The parser is instrument firmware. It is outside anything NI's driver group supports.	Build and test the parser as a firmware deliverable. Validate it with raw VISA reads and writes before any driver VI exists.
Writing a "VISA driver" that runs on the instrument	VISA runs on the host. The instrument only has to present a transport that VISA can open.	Expose a serial port, a LAN instrument or socket endpoint, and a USB test-and-measurement interface. Then write the LabVIEW driver on the host side.
Starting from older templates to keep backward compatibility	Reviews are run against the 2014 revision.	Use the 2014 templates. NI has saved them back to LabVIEW 8.2.
One VI per SCPI command	This is a standard review rejection. It inflates the API and repeats parameters across many VIs.	Combine related commands into one VI, as the templates show.
One high-level VI that configures, triggers, and reads	Mixing Configure, Action-Status, and Data subVIs in API VIs is rejected.	Keep the API granular. Combine these steps only in example VIs.
Removing or password-protecting block diagrams before submission	NI cannot certify a driver whose diagrams it cannot inspect.	Ship the driver with open diagrams.
Submitting without any automated pre-check	The first review step is an automated guideline check. A driver that fails it comes straight back.	Run VI Analyzer against the driver-guideline tests first.

Boundary between VISA and instrument firmware

VISA is a message-based I/O layer. On a write, it moves the bytes of a command string to the transport and appends a termination character if you configure one. On a read, it returns bytes until one of three things happens: it sees the termination character, it reaches the requested byte count, or the VISA timeout expires. The driver VIs format strings and parse replies. The firmware parses strings and formats replies. Every problem in bring-up sits on one side of that line.

One test decides whether the firmware is ready for driver work. Send a bare identification query (*IDN?) through VISA on each interface and check that it returns the correct identity string within the VISA timeout. If the read hangs until timeout on serial or raw socket, the instrument's reply termination and the VISA termination-character setting do not match. That is a framing problem, not a driver-logic problem.

Interface	What the instrument must present	VISA resource name pattern	Quantity to check
Serial	UART at a fixed baud, data bits, parity, and stop bits, with a termination character	ASRL<n>::INSTR	Serial settings match on both ends. The reply ends with the termination character that VISA is set to stop on.
Ethernet (instrument protocol)	A LAN instrument service	TCPIP0::<host>::INSTR	The resource opens and *IDN? returns before the timeout.
Ethernet (raw socket)	A TCP listener on a documented port	TCPIP0::<host>::<port>::SOCKET	Termination character is enabled for reads. Without it, reads end only on byte count or timeout.
USB	A USB test-and-measurement class interface	USB0::<vendor>::<product>::<serial>::INSTR	The device enumerates under VISA, not as a generic serial or HID device.

Once all supported interfaces return a clean identity string, the driver can treat them the same way. That is why the guidelines require the VISA resource name as an input on every VI rather than a hard-coded interface.

LabVIEW environment settings before the first API VI

Set these options in LabVIEW's Options dialog, under the Front Panel and Block Diagram categories, before you create any API VI. Any VI created before the change keeps the old defaults, such as icon-style terminals and automatic error handling. Each of those becomes a review finding you then have to fix one VI at a time.

Area	Required setting	What the reviewer sees if it is wrong
Front panel	Same color on every panel	Visual inconsistency across the API
Front panel	Modern 3D style for controls and indicators	Mixed control styles
Block diagram	Use transparent name labels enabled	Opaque label boxes cluttering the diagram
Block diagram	Automatic error handling in new VIs disabled	Hidden error dialogs instead of errors passed through error in and error out
Block diagram	Place front panel terminals as icons disabled	Oversized icon terminals on the diagram
Window state	Front panels and block diagrams not maximized	Windows open full-screen on the reviewer's display

API structure from the 2014 templates

Start from the Instrument Driver Guidelines and the 2014 revision of the templates. NI also offers the Instrument Driver Development Studio for driver development. If you use it, load the latest templates into it rather than its bundled defaults.

Backward compatibility is a version decision, not a template decision. The 2014 templates have been saved back to LabVIEW 8.2. Pick the oldest LabVIEW version your users actually run, no earlier than 8.2, and develop in that version from the first VI. LabVIEW saves backward but does not open forward, so a driver built in a newer version shuts out every user on an older one.

1. Group commands by function and combine related commands into a single VI. Remove redundant parameters so each setting appears in one place.
2. Keep the Configure, Action-Status, and Data layers as separate VIs. Chain them together only in examples.
3. Use the 4-2-2-4 or 5-3-3-5 connector pane pattern on every VI. Follow standard LabVIEW practice for terminal placement: VISA resource name in and out across the top corners, error in and out across the bottom corners.
4. Make the VISA resource name a Required input on every VI, with no exceptions for utility or close VIs.
5. Lay out each diagram left to right and top to bottom, following the data flow. Use one consistent writing style across every VI in the driver.
6. Draw meaningful icons. All-text icons are discouraged, and icons picked at random fail review.

Controls, strings, and the decimal separator on the wire

The most common certification failure that only shows up in the field is a locale fault. On a PC whose regional settings use a comma as the decimal separator, LabVIEW formats 1.5 as 1,5 by default. The instrument's parser then either rejects the value or reads it as two separate arguments. The fault shows up in the instrument's error queue, and it happens only on some host PCs. That pattern is the signature: the same VI works on one machine and fails on another, with no change to the instrument.

• Add %.; to the format string when converting floating-point numbers with Format Into String or Array To Spreadsheet String. This forces a period as the decimal separator no matter which locale the host uses.
• Wire a False constant from the Boolean palette to the Use System Decimal Point terminal of Number To Exponential String and Number To Fractional String.

Control choice rules that reviewers check:

• Use a Boolean control only for true opposite states. That usually means the command itself takes 0/1 or True/False. Show it as a vertical slide switch.
• Use a text ring for any setting without two clear states.
• Avoid string controls in the API. Use numeric controls or text rings. Where a string would otherwise be needed, use a file path control or timestamp control.
• Use a Select function, not a Case Structure, to choose between two wires.
• Do most string building and parsing with Format Into String and Scan From String. Pick Line and Append True/False String are also acceptable. Use Concatenate Strings sparingly, and only when no better string function fits.

Documentation rules:

• Document every VI, control, and indicator. Include at least one comment on each block diagram.
• Start every VI description with a verb.
• State any restrictions. Examples: a mode that prohibits using the VI or control, or an instrument model that does not support it.
• Use meaningful names with the first letter capitalized. Avoid symbols, and avoid abbreviations unless users worldwide already know them.

Review findings versus root cause

Review finding	Root cause	Correction
Too many API VIs, repeated parameters	One VI per command	Combine commands following the template pattern
High-level VI rejected	Configure, Action-Status, and Data mixed in one API VI	Split them. Combine only in examples.
Numeric values wrong on some host PCs	Locale decimal separator applied to formatted numbers	%.; in format strings, and False wired to Use System Decimal Point
Boolean control flagged	Setting has more than two states, or states are not opposites	Text ring
String control flagged	Free text used where a list of values exists	Text ring, numeric, path, or timestamp control
Undocumented VI or control	Missing descriptions or restrictions	Verb-first descriptions, restrictions listed, one diagram comment minimum
VI cannot be wired into a chain	Non-standard connector pane, or VISA resource name not Required	4-2-2-4 or 5-3-3-5 pattern, VISA resource name Required
Driver cannot be reviewed	Block diagrams removed or password-protected	Resave with diagrams intact

Test coverage and the certification package

1. Build at least two example VIs with meaningful names. Test and document each one.
2. Test every VI, and exercise every combination of options on each front panel.
3. Repeat the tests on every interface the driver claims to support: serial, Ethernet, and USB if all three are implemented. A driver that works only on Ethernet must not advertise USB.
4. Record known issues, interface quirks, and any other user-relevant notes in the Readme.
5. Prepare the instrument's programmer or user manual with the full command set. It is a required part of the submission, because reviewers check each VI against the commands it sends.
6. Submit the driver and manual to the NI Instrument Drivers/IVI Group at [email protected]. The same group can confirm current certification requirements and recommended practices before you start.

Pre-screening the driver with VI Analyzer

An automated check against the instrument driver guidelines is the first thing a certification reviewer runs. A VI Analyzer plug-in for instrument driver validation has existed for this purpose. Depending on your installation, it may ship with VI Analyzer or with the Instrument Driver Development Studio. Look at the test list in your VI Analyzer configuration to see whether driver-guideline tests are present.

1. Open VI Analyzer and add the whole driver library, including the examples.
2. Enable the instrument driver guideline tests alongside the standard style and documentation tests.
3. Run the analysis and fix every failure. Rerun until the driver-guideline tests report zero failures.
4. Manually review the items automation cannot judge: whether icons are meaningful, whether descriptions start with a verb and state restrictions, and whether names avoid obscure abbreviations.
5. Run the examples once more on each supported interface before you package the submission.

FAQ