Instrument drivers take some of the sting out of controlling test instruments by adding an abstraction layer.

Almost everyone who uses computers has had experiences with drivers, and probably not good ones. In the olden days, if you had wanted to hook an old printer up to a new computer, you would have searched through file cabinets hoping to find the CD (or even the floppy disk) that came with it. Now, you search the web, hoping your printer manufacturer still offers a driver for the printer you may have bought years ago, or recently from a yard sale. Similarly, if you want to hook up an instrument or any other peripheral hardware to your computer, you will likely need a driver.

But why do we need drivers, anyway?
Drivers provide a layer of abstraction between you and your peripheral hardware. When you want to print a document, you simply issue a print command. You, and your operating system, don’t need to specify how to position the print head and what inkjets to fire at any given time. The driver takes care of the details. And if you want to read a voltage on channel 2 of your digital multimeter (DMM), you simply issue a “get_voltage_channel_2” command. You don’t have to worry about what relays or switches to flip inside the DMM to enable channel 2. The driver handles that.

So, I just get a driver, install it, and forget it, right?
Drivers are operating-system-specific, so make sure you choose the appropriate one. You might also want to give some consideration to the type of driver you are getting. Keep in mind you can interact with an instrument in a couple of ways (Figure 1): through a graphical user interface (GUI), which brings the instrument’s front panel to your computer screen, and through a test program, which can automate your test-and-measurement tasks.

For the GUI, a simple plug-and-play driver should suffice. When you replace your instrument, you’ll get a newer, better one with its own GUI. Test programs, written in C, LabVIEW, or some other high-level language, do present some issues, though. Over the years, you might have made quite an investment in test-program development, and you don’t want to have to extensively modify your test programs every time you get a new oscilloscope or signal generator. To keep things simple, you should choose a driver that conforms to the Interchangeable Virtual Instruments (IVI) standard, maintained by the IVI Foundation.

Are there IVI drivers for all instruments?
The IVI Foundation defines several classes of instruments, including DMMs, oscilloscopes, arbitrary-waveform/function generators, AC and DC power supplies, switches, power meters, spectrum analyzers, RF signal generators, upconverters, downconverters, digitizers, and counter/timers. If you choose IVI drivers, you can control these instruments using the Standard Commands for Programmable Instrumentation (SCPI), which the IVI Foundation also maintains. With SCPI and an IVI driver, you would need minimal if any changes when swapping one instrument for another within a given instrument class.

Where do I get a driver?
Most instruments come with drivers for Windows, or you can download them from the manufacturer’s website. Many manufacturers also provide LabVIEW drivers. NI maintains a repository of LabVIEW drivers in its Instrument Driver Network. Of course, you can write your own driver if you can’t find one. Many people have uploaded drivers to repositories; but keep in mind that unless a driver is certified by the instrument manufacturer, it may not support every instrument function.

Is there an alternative to drivers?
Yes. Some vendors are beginning to leverage Internet-of-things technology and machine-to-machine (MTM) communications; they are adding a Representational State Transfer (REST) application programming interface (API) to their instruments. The REST API enables what is called RESTful web services, which often employ the hypertext transport protocol and the JavaScript Object Notation (JSON) data-interchange format. These services enable you to access an instrument from any browser running on any operating system. Say, for example, you have a group of instruments normally connected to a Linux host, but you want to do a quick check of a DMM’s channel 2 voltage level using your Android smartphone. If the DMM supports the REST API, you just open a browser on your phone and issue a command such as this one:

http://www.MyDomain.com/MyDMM/get_voltage_channel_2

Will REST replace drivers?
Test engineers will continue to prefer drivers because of their legacy test code and their familiarity with IVI and the associated Virtual Instrument Software Architecture (VISA), which also applies to plug-and-play drivers. Additionally, test-equipment vendors may resist supporting both the REST API and drivers. REST may make inroads in data-acquisition systems that potentially involve remote monitoring, but for situations where your DUT and instruments are in the same lab, you can expect drivers to be around for a long time.