More on Instrument Drivers

As I mentioned in my last post, instrument drivers provide a somewhat higher-level abstraction for talking to instruments. If you've used LabVIEW to talk to instruments, you probably also realize that instrument drivers come in a lot of flavors--VXIpnp, IVI-C, IVI-COM, LabVIEW Plug and Play, ... I'll try to help you sort those out.

Further, you've probably seen that NI certifies some of the instrument drivers on IDNet. What does that mean? I'll try to clarify that, too.

Keep in mind that this is a very abbreviated history, and there were a lot of details I'm leaving out...

In the beginning, instrument drivers were simple...

We had a guy sitting one room over from the LabVIEW area who wrote instrument drivers. We'd borrow instruments, bring them in house, and he'd write a few VIs to get them to take measurements. (Often, he'd also write an instrument driver for LabWindows.)

There weren't any standards, but most drivers for LabVIEW and LabWindows were pretty consistent, because there was only one guy writing them.

With a lot of help from National Instruments, the test and measurement industry started to pay more attention to software. Instrument vendors and end users started writing drivers, but there were a lot of different philosophies on what an instrument driver should look like. This made it harder for end users--they might be able to find a driver for their instrument, but they didn't always know what they were getting, or how to use it.

The VXIpnp standard

VXI (VME Extensions for Instrumentation) was an instrumentation bus standardized in the late 1980's. Out of that grew a push for more standard instrument driver software in the VXI Plug and Play (VXIpnp) Systems Alliance.

This standard specified a few items common to all instrument drivers--Initialize, Close, Error Handling... But it was pretty much measurement-agnostic. Once you got past Initialize, there was no consistency in how you configured the instrument or took a measurement.

One key aspect of VXIpnp drivers is that they require the use of VISA. This paid off in the long run, since it allows us to have a single instrument driver for an instrument with serial, GPIB, Ethernet and other connectivity.

The VXIpnp standard defined standards in multiple programming languages, including C and LabVIEW. These days, though, when you hear that a driver is VXIpnp, it is almost certainly a C driver. (Which can be used in LabVIEW by creating wrapper VIs around a DLL with an automated tool you can download from IDNet.)

The IVI League and the IVI Foundation

Skipping ahead a few years, National Instruments and some our customers created a group informally called the IVI League. The idea was to take the instrument driver software standard further--defining instrument classes, such as DMMs, Function Generators, Oscilloscopes, etc., and standardizing more of the instrument driver API.

To make progress, we knew we needed to bring in other hardware vendors, and the IVI Foundation was born. Over the course of several years, the APIs were further refined, and new instrument classes added.

IVI drivers bring a lot of advanced features. Unfortunately, they're harder to write--most are written in C or C++. This means that they're harder for end users to customize or debug. It also means that there aren't as many IVI drivers as, for example, native LabVIEW drivers.

LabVIEW Plug and Play: Bringing Back LabVIEW Drivers

As I went out and visited customers, I got a lot of feedback that they weren't entirely enthusiastic about using C-based VXIpnp or IVI drivers in LabVIEW.

IVI drivers were supposed to be more robust than earlier technologies, but customers still wanted to be able to debug their test system and step through the code. Other customers wanted to restructure the driver, or make additions to it, or optimize it. Without a C programmer on staff, this was practically impossible. IVI drivers from some other vendors didn't even include source code, so you couldn't modify them.

The LabVIEW users were willing to trade off all the IVI features for a much simpler, native LabVIEW source code instrument driver--the way we originally started. This let them make their own optimizations and enhancements.

So in LabVIEW 8.0, we rolled out the idea of "LabVIEW Plug and Play" instrument drivers. The VIs leverage the structure of VXIpnp and IVI drivers, but they fit more naturally into LabVIEW, and they include native LabVIEW source code.

LabVIEW 8 Makes Instrument Drivers Easier to Use and Easier to Develop

In LabVIEW 8, we added the Instrument Driver Finder, to make it easier to find and download instrument drivers. Our instrument driver development group started developing drivers to our improved standards. We've worked with vendors to improve LabVIEW support for their instruments.

We also made it easier for our end users to develop drivers, with the Instrument Driver New Project Wizard, and Instrument Driver VI Creator. We enhanced our Instrument Driver Development Guidelines and our Instrument Driver Templates.

In LabVIEW 8.20, we've even created a tool that lets you export LabVIEW drivers to other environments that use C.

So What Kind of Driver Should I Use?

Okay, so there's the brief history. What does it all mean? For LabVIEW users that want to talk to 3rd party instruments, you should look for Certified LabVIEW Plug and Play instrument drivers. You can use the Instrument Driver Finder, or search on your own at IDNet.

If you can't find one at NI's site, ask the vendor for a LabVIEW Plug and Play driver.

If you can't find a native LabVIEW driver, you have a few options. If you can find the instrument's command set, consider writing your own; it's not that hard.

If the vendor has a VXIpnp or IVI-C driver, they may also supply LabVIEW wrappers. Those work well, but you may not be able to modify/debug the driver.

If the vendor has a .Net or IVI-COM driver, you can use it in LabVIEW using our native .Net and ActiveX programming.

Future Topics

Okay, I didn't cover a couple of things I said I would...

• What does "Certified" mean?

• What's the difference between IVI-C and IVI-COM

I'll work on those in upcoming posts.