Software in the driver's seat

Edited by Leland Teschler

Michael Neal
National
Instruments Corp.
Austin, Tex.

A midnight mission over Fallujah is a bad time to discover problems with an aircraft's avionics. A glitch in a first-person shooter game at a key point in the action can be a great source of aggravation. These are two examples of why technology deployed in a wide variety of fields must be re-liable. This need for reliability is fostering greater reliance on automated test systems during development and production.

Testing today can be as important as any other facet of a development project. There is a substantial amount of testing involved in even moderately complex products. That's why tools are continually developed to more fully automate the creation of software for automated test systems. Because devices that these systems must wring out are increasingly complicated, there is a premium put on developing custom test systems quickly and efficiently. This trend has also led developers toward modular hardware whose functions can be redefined on the fly by software to handle tests at hand.

For instance, consider an ordinary cell phone. Its test regime may cover qualities that involve the digital display, power supply, and mechanical components such as buttons, as well as the quality and strength of the phone signal. Traditional setups based on dedicated test instruments are generally limited to just the specific function for which the instrument was designed. There's little opportunity to customize test functions if new products or product features come along.

Modular test instruments, with functions controlled by software, address this need for flexibility. A typical automated test system taking this approach can be thought of as comprising several layers, with the measuring devices at the lowest level. Measuring hardware communicates back to a controller that serves as a coordinating device by means of an instrumentation bus. The most widely used buses include GPIB, serial, USB, Ether-net/LAN, PCI, and PXI.

There are advantages to each of these formats, and test systems may host instruments having connections for more than one. GPIB, for example, has been in use for decades. So there is a wide variety of instrumentation available with a GPIB interface. USB is the connection format for common computer peripherals such as mice, minicams, and printers. Every PC comes equipped with USB ports for plug-and-play connectivity. Ethernet, of course, makes possible distributed measurements and the communication of results over long distances. The modular architecture of the PCI (and, by extension, PXI) instrumentation bus is characterized by open standards and thus there is an appreciable amount of software freely available to create systems for a variety of uses.

The means by which an instrument communicates over a bus is worth some discussion. The software that lets an instrument talk with external devices such as controllers is called an instrument driver. Thus there are drivers that allow control of instruments connected to a computer via the various bus protocols.

But there can be differences in how driver software functions. The most primitive driver routines consist of low-level protocols and commands that inter-act directly with the instrument's interface hardware. However, instrument drivers have evolved in the same way as widely used application programs to incorporate GUIs that make life easier. Many drivers employ high-level APIs that simplify the creation of test regimes and accelerate development.

As a whole, instrument drivers offer a uniform way to get output data from instruments into routines for analysis, data logging, and presentation. They also simplify the task of creating software to test features in a particular device.

For example, consider the task of setting up a data-acquisition routine. It can involve sending a sequence of low-level commands to the instrument to establish the input range, number of samples, and other required configuration information. But a modern instrument driver typically provides a single function to set all these parameters simultaneously. In so doing, it takes on a role once occupied only by application programs. It thus reduces programming overhead without sacrificing performance.

There are two styles of these modern instrument drivers that are in the mainstream: VXI-plug&play and Interchangeable Virtual Instrument (IVI) drivers. VXI is an instrumentation bus first defined in 1987. Through the years a wide variety of instruments from numerous manufacturers have been designed to work over VXI. The VXIplug&play standard was created in the early 1990s as a route to eliminate issues with software interoperability among VXI devices from different vendors. The standard lays out guidelines for key software and hardware integration practices including standardized naming conventions and file formats. Among the structures defined under VXIplug&play is a layer of communication I/O software called VISA which provides a standard set of function calls and data structures compatible with every VXI instrument's software. It is the underpinning for standard treatment of soft front panels and instrument drivers.

A key part of the VXIplug&play framework is ability to provide programming language interoperability, irrespective of what company made the instrument. And instrument drivers can be created in ANSI C source code-compatible languages or via virtual-instrument programs created on the National Instruments LabView graphical-development platform.

IVI drivers, on the other hand, focus on instrument interchangeability. They address areas that VXIplug&play does not handle and introduce the concept of functional instrument classes (oscilloscopes and digital multi-meters are examples). All instruments of the same class share a common class driver that handles generic functions. For example, two IVI drivers for function generators share the same number of inputs/outputs, and the same terminal pattern. The instrument driver adjusts parameters to account for differences between individual instruments. In the case of function generators, the output amplitude is always defined to be volts peak-to-peak, not volts peak or volts rms.

The interface to each driver VI is the same, but users can get extensions for functions that only come on a particular instrument (though these extensions may not be defined in a standard manner). There are two types of IVI drivers — one based on ANSI C and the other on Microsoft COM technology. These different IVI architectures can coexist, so IVI-C and IVI-COM drivers can reside in the same test system.

IVI-COM drivers are particularly handy for instrument inter-changeability. IVI-COM drivers are based on Microsoft ActiveX technology and work in many different software-development environments. But they are not open source, unlike IVI-C and NI LabView source-code drivers. This factor comes into play because most instrument drivers do not cover every function a particular instrument offers. So it may be difficult to augment existing driver functions or add new ones if the base driver is in a proprietary format.

Open-source drivers are also useful when a function returns an unexpected error. You can un-earth information on the cause by stepping through the function subroutines one-by-one. But that is possible only when you have the instrument driver source code, whether the driver is native to C, C++, Visual Basic, or LabView.

IVI-C instrument drivers also offer state caching. That is, they use a software code to keep track of the physical state of the instrument. This boosts the speed of the driver functions by eliminating transmission of redundant commands in cases where several would otherwise be grouped together in a high-level driver routine.

ANSI C source code is often available for IVI-C drivers. These IVI-C drivers can be called from a C compiler, as well as from Lab-View, C++ and .NET through custom wrappers. This is an advantage for those engineers knowledgeable in C. But for many test engineers, LabView is a preferable software-development environment because of its intuitive programming paradigm and tight integration with hardware.

As a quick review, LabView is a graphical-development environment that includes the general-purpose functions of a traditional high-level programming language (loops, data types, and variables). It also incorporates hundreds of hardware I/O, communication, analysis, and presentation functions useful for scientific and engineering applications. There are thousands of fully functional, LabView source-code instrument drivers online at the National Instruments Web site.

A LabView driver controls most instrument functions and can let users customize the source code as needed. For example, they might remove unwanted functions to make the driver run faster. The most recent version of LabView (Lab-View 8) helps locate appropriate instrument drivers through use of a feature called Instrument Driver Finder. It identifies connected instruments and automatically downloads and installs corresponding LabView source-code drivers from the National Instruments Web site. It searches for instrument drivers using parameters that include the manufacturer name, model number, or a keyword.

Once a driver is located, the Instrument Driver Finder lets users view driver ratings and information on supported models, as well as lists of any supporting software needed to run the instrument. The point of this additional information is to better assess the quality of a driver before it's integrated into a system.

Though there are numerous LabView instrument drivers on-line, new ones are created constantly to handle less common instruments. Many users are comfortable changing LabView driver code, but creating a custom instrument driver from scratch is traditionally an ambitious venture. To address this problem, LabView 8 includes an Instrument Driver Project Wizard to help generate source code from templates or existing drivers. Templates cover such common instruments as power supplies, digital multimeters, and oscilloscopes. There also is a general-purpose template for instruments outside these categories.

The project wizard also gives all driver functions a consistent appearance and voluminously documents parts of the code for later modification if need be. Although this tool generates working code, it cannot automatically create a completely custom driver from scratch. Nevertheless, it gives users a more advanced starting point.

MAKE CONTACT
National Instruments Corp., NI.com