A Universal Instrument Driver

by Joseph B. Travis

 

Importance of Instrument Drivers

Instrument drivers are a key to rapid development of test and measurement applications.  A typical test and measurement task commonly requires at least four different instruments.  If drivers don’t already exist for the instruments, it is a pretty safe bet that a major portion of the coding effort will be spent developing the drivers.  However, if the drivers do exist, you can focus your efforts on the task at hand.

 

Common Instrument Driver designs

The typical LabVIEW model is a multifunction approach that consists of a library (.llb) file containing component VIs.  These VIs fit into six categories: initialization, configuration, action/status, data, utility and close.  This design was architected many years ago by National Instruments and is still being followed today.

 

The Interchangeable Virtual Instrument (IVI) model is a multilayered approach that groups instruments into five generic classes: oscilloscope, DMM, arbitrary waveform/function generator, switch and power supply.  The program will make calls to the class drivers, which in turn make calls to specific instrument drivers to control the actual instrument.  The advantage of an IVI driver is the ability to change instruments without affecting your code.

 

The problem as I see it…

From a programmer’s perspective, the aforementioned designs contain a lot of overhead that I would not care to know about.  The sequence of steps necessary to communicate with an instrument is much more complicated than it really needs to be.  For example:

 
  1. Open and initialize the driver
  1. Configure the instrument
  1. Perform an action (write)
  1. Read status / result
  1. Repeat steps 3 – 4 until done
  1. Close the driver

 

There are simply too many VIs that you must know about in order to effectively be able to develop code.  The problem grows with the number of instruments that you must support in your program.

 

Work smarter, not harder

A few years ago, I had the task of creating a Test Executive that would configure, control and launch an unlimited number of tests using a variety of instruments (about 30+ at that time).  Most  of the instruments did not have drivers available.  I had to either write a large amount of code in a short period of time or devise a method that would reduce the amount of code needed.

 

After I had put together a design draft that outlined the entire Test Executive program, I determined that the easiest way to reduce the amount of code necessary was to avoid the use of specialized instrument drivers.  I’m a firm believer in KISS (Keep It Simple Stupid) and made it one of my design goals to create a VI that would be the single point interface to all instruments.

 

Universal Driver Design Objectives

The main design objectives focused on making the programmer interface easy to use, easy to read and easy to maintain.  More specifically, the goals were:
  • Use ASCII configuration files for each instrument
  • Use keywords as macro commands for the instrument
  • Use reserved keywords for configuration information
  • Use VISA to help keep interface type (GPIB, RS-232, etc.) transparent
  • Keep all VISA functions and references internal to the driver
  • Provide driver intelligence such that a read/write operation is automatic without the use of a switch and that a read is automatically performed after a query command is sent
  • Provide commands for GPIB functions CLR, STB and TRG
  • Provide intelligent error handling for I/O card, bus and instrument issues
  • Use semaphores to permit multiple VIs to run concurrently, allowing access to different instruments without contention

 

A Simple Driver Comparison

From the NI Developers Zone, I downloaded the traditional and IVI driver libraries for the hp66xxa series power supplies.  The reasons behind this choice are that (1) it is a simple instrument that everyone can understand and (2) both driver designs were available.  A simple comparison of the three libraries follows:

 

Traditional                   IVI                    Universal Driver

LLB file size                             551K                             1,112K              453K

VI count (less examples)          14                                 35                     11 *

 

* Note: Although the Universal Driver has 11 VIs total, you only need to use one to interface with any instrument.

 

Figure 1 is an example of how one might setup an HP66XXA power supply using the traditional device driver method.  There is nothing fancy about the code however, it does take four VIs to perform a simple setup and read back the voltage and current.

 

Figure 1 – Traditional device driver method

 

Figure 2 is a similar example using the IVI driver method.  This one uses nine VIs to accomplish the same simple task!

 

Figure 2 – IVI driver method

 

Figure 3 depicts how one might perform the same task using the Universal Driver.

 

Figure 3 – Universal Driver method

 

The diagram shown in Figure 4 is a typical test program initialization sequence.  As you can see, the Universal Driver is being used to initialize six different instruments.  The BERT Auto Sync VI that you see is an algorithm that works with several different models of BERTs from Agilent, H-P and Anritsu.  It also uses the Universal Driver.

 

Figure 4 – Test equipment initialization sequence using the Universal Driver

 

Universal Driver Code Description

Figure 5 shows a snippet of the Universal Driver code.  As mentioned previously, semaphores are used to avoid contention when multiple VIs or applications are running and communicating with different instruments simultaneously. 

 

The directory input tells the driver where to find the instrument configuration file.  If empty, it will look in the current directory in which the driver VI resides.  The instrument string input is for the instrument model e.g. HP8133A or TEK11801A, etc.  The driver uses these two inputs to build a path to the configuration file, from which it will read the GPIB address and GPIB Delay.  Normally the GPIB address would contain a numerical value 1 – 30.  However, if the instrument uses the serial port, it would be a string such as: COM1,9600,N,8,1.  The driver will parse this, configure and open the serial port accordingly.

 

Figure 5 – Universal Driver code showing use of semaphores and VISA driver

 

In Figure 6, the write buffer input is used to determine whether the driver will send or receive data to or from the instrument.  If it is empty, it will perform a read, else, it will process the buffer one line at a time.  The write option control determines if and how the driver will process the write buffer string.  The options are:
  • Normal – searches the configuration file for a matching keyword.  If the keyword is found, it will send out the list of commands beneath the keyword.  If no keywords match, it will send out the string to the instrument.  This is useful when initializing instruments with a lengthy list of commands.
  • Write Direct – Will bypass the keyword lookup in the configuration file.  This is much faster than Normal and is typically used during test execution.
  • Write Binary – Will bypass all string processing and send the write buffer directly to the instrument.  This is the fastest mode of the three and is typically used to download large binary patterns to a BERT (Bit Error Rate Tester) or similar instrument.

 

Figure 6 – Universal Driver write buffer processing

 

Note that some older GPIB instruments have limited buffer size that can overflow, causing commands / data to be lost or ignored.  The GPIB Delay parameter in the instrument’s configuration file is used to “throttle” down the commands allowing the instrument time to process them.  A GPIB Delay parameter of 100 would cause a 100mS delay to be inserted between each command.  Figure 7 shows the delay function in the upper left corner of the while loop.  This figure also shows how commands are processed a line at a time with an automatic read being performed after a query command has been sent.

 

Figure 7 – Universal Driver “throttled” command processing

 

The byte count input (not shown) sets the read buffer size, the default is 1000.  The driver’s Timeout input is defaulted to 10,000 mS (10 seconds).

 

The read buffer output is the concatenated response from a query.  With the Universal Driver, you can send multiple queries to an instrument and the driver will automatically read each response and concatenate them into one string.  This string may be easily processed by the Scan from String.vi.  The advantage here being that you can make multiple queries to an instrument with just one call to the Universal Driver vice multiple calls to the write and read VIs of another driver.  Less overhead, easier to read and understand.  The byte count output will have the number of bytes in the read buffer.

 

Shown in the Figure 8 diagram is the error handling for the Universal Driver.  A case structure is used to trap specific errors and translate them into a more user friendly format, offering a list of suggestions on how to remedy the problem.  Such errors include:
  • No GPIB interface card installed
  • Can’t find the specified instrument at GPIB address
  • Instrument timeout
  • Instrument access
  • Serial port access

 

Figure 8 – Universal Driver error handling

 

A sample instrument configuration file (TEK11801A.cfg) for the Tektronix 11801A shows what a typical DSO (Digital Storage Oscilloscope) file might contain.  The Test Executive that I’ve created uses the Substitutes keyword to identify suitable instrument substitutes.  It searches the GPIB bus to ensure the instruments necessary for a given test are online before executing the test.  You’ll also notice that keywords such as *IDN? and *LRN? are used to translate the equivalent Tektronix commands into IEEE-488 standard commands.  The *STB? and *CLR will translate to ~STB? and ~CLR which the Universal Driver will handle internally to perform the respective GPIB function.

 

Conclusion

The Universal Driver has been a tremendous time saver in developing nearly 300 different tests and GUIs, with many more to come.  We never waste time debugging driver code.  If a change needs to be made to an instrument setup, it is done in the configuration file and is propagated to all tests that are affected without having to edit the code.  This Universal Driver design method promotes code development that is easy to read and maintain while being highly reusable.  In comparison to the other driver methods, the .llb file size is only 453K and only requires one VI to do it all!

 

About the author:

Joseph Travis is a Principal Engineer at Applied Micro Circuits Corporation (AMCC) in San Diego, California.  He is also a consultant (dba Solutions InVIEW) and has been programming with LabVIEW since 1994.  He may be contacted by email at: n6ypc@amsat.org.

 

References:
  1. National Instruments Application Note 111, LabVIEW Instrument Driver Standards, by Noël Adorno, March 1998
  1. National Instruments Application Note 006, Developing a LabVIEW Instrument Driver, by Noël Adorno, May 1998
  1. National Instruments Application Note 121, Using IVI Drivers to Build Hardware-Independent Test Systems with LabVIEW and LabWindows/CVI, by John Pasquarette, September 1999