ChipCenter Questlink
SEARCH CHIPCENTER
Search Type:
Search for:




Knowledge Centers
Product Reviews
Data Sheets
Guides & Experts
News
International
Ask Us
Circuit Cellar Online
App Notes
NetSeminars
Careers
Resources
FAQ
EE Times Network
Electronics Group Sites

  Tech Note

T&M Main | Archives | Feedback

Tune Up Your Test System With IVI Drivers

Jump to...
The IVI Spec
Increasing Productivity
Swappable Drivers
The Simulation Advantage
Boosting System Performance
Dealing With Defaults

Software instrument interfaces play a significant role in achieving test suite performance. The Interchangeable Virtual Instruments Foundation's specs for instrument driver software can increase test system performance, decrease long-term maintenance costs, and boost software development productivity

By Dany Cheij, Test and Measurement Product Manager, National Instruments, Austin, TX. (512) 683-5286, or e-mail: dany.cheij@ni.com.

A major factor in production efficiency is the effectiveness of your testing system. By having a high-performance efficient system, you can build and test products faster and cheaper.

While the performance of a test system is largely determined by its hardware and hardware interface bus, the software interface to instruments can also play a significant role in improving performance.

Software interfaces to instruments are called instrument drivers. They're generally designed to provide high-level function calls that abstract the details of programming an instrument for specific actions.

In recent years there have been several industry initiatives to create specifications for instrument drivers that standardize the way manufacturers program. The latest--and possibly the most effective such attempt--is the Interchangeable Virtual Instruments (IVI) Foundation.

The IVI Spec
Return to Top

The IVI Foundation was created in 1998 with the goal of defining a standard programming interface for instrument drivers. The idea was to build on existing approaches, such as VXIplug&play, and address performance, development productivity, and cost issues associated with instrument programming.

The IVI Foundation has defined specifications for instrument classes, such as oscilloscopes or digital multimeters (DMMs). Each of these specs defines a set of basic and extension capabilities that an instrument can support. The specs also define high-level functions that are used to program an instrument.

The Interchangeable Virtual Instruments Foundation finalized a number of instrument classes, but also has a number of classes in the process of being defined. The IVI is also defining new instrument classes.

Additionally, the IVI specs define an architecture for IVI systems that incorporate productivity features. These features include instrument interchangeability, instrument simulation, and system performance, to name a few.

Currently five instrument classes are completely defined: (1) DMMs, (2) oscilloscopes, (3) DC power supplies, (4) arbitrary waveform or function generators, and (5) switches or multiplexers. The Foundation is currently working on expanding the list to include instruments such as spectrum analyzers and RF signal generators.

Increasing Productivity
Return to Top

IVI drivers can increase software development productivity by providing you with several benefits over the life of your system. These benefits include instrument interchangeability, instrument simulation, and test system performance.

This oscilloscope driver simulates what you'd see on-screen for an analog data channel.

One of the main benefits of IVI is instrument interchangeability. In addition to creating specifications for instrument classes, the IVI Foundation defined an instrument driver architecture that's divided into two parts. First, there's an instrument-specific driver that's designed for a particular instrument. It provides benefits such as simulation and state-caching.

Secondly, there's a generic class driver that provides for instrument interchangeability. The class driver uses generic software functions that are mapped to corresponding functions within the specific driver. These functions are the same for any instrument in that class, and have a standard function prefix and function prototype.

Swappable Drivers
Return to Top

By writing a software program that uses these class drivers, developers are capable--at a later time--of replacing the instrument in a system by swapping instrument drivers in a configuration utility or file.

For example, the specific instrument driver for the Hewlett-Packard HP34401A DMM contains functions with the standard prototype for that instrument, such as hp34401a_Init. This initialization function is specific to this driver and can only be used with the corresponding instrument.

The DMM class driver contains functions with the generic class prefix, such as IviDmm_Init. As an example, if a user writes a program using that function, he or she can swap the National Instruments NI4060 computer-based DMM for the original DMM without having to modify any code.

This presents several advantages if you're a software developer. You're now able to concentrate on designing a system that's capable of meeting technical requirements, rather than concentrating on the details of developing a system that can be reused in the future.

Development productivity is also increased in the long run. When instruments in a system become obsolete and need to be replaced, you can concentrate on improving overall system design, instead of rewriting and recompiling individual test modules to be compliant with a new instrument.

Interchangeability enables developers to share test code with others who don't have the same hardware. It also lets you upgrade outdated or defective instruments without having to rewrite software, and permits the development of a test system that's compatible with multiple vendor test instruments.

The Simulation Advantage
Return to Top

With traditional/conventional instrument driver implementations, when the initialization function is called, the driver communicates with the instrument to set up the instrument. It also returns a software handle to that instrument that can be used in subsequent function calls to identify the instrument.

If the instrument isn't physically connected to the host computer, however, the initialization function fails and an invalid instrument handle is returned. IVI corrects for this behavior, because users can configure instruments for simulation. When the initialization function in an IVI instrument driver is called, the driver checks to see whether it's configured for instrument simulation, and if it is, the initialization function passes, and a valid instrument handle is returned--regardless of whether an instrument is actually present in the system.

Instrument-specific drivers are also designed to return basic data (which is usually random), in order to simulate the measurement capabilities of the instrument. With advanced-class simulation drivers from National Instruments, for example, users can return more advanced and customized measurement data, as well as simulate instrument errors and status responses.

Simulation provides the user with many benefits, including the prototyping a test system in software prior to purchasing hardware, and sharing one set of test hardware among a team of developers. The latter can cut development time and lower cost.

Boosting System Performance
Return to Top

IVI provides several integrated features to address system performance; these directly affect development productivity. These features include state caching, range checking, interchangeability checking, and spying. Let's look a bit more closely at each.

State caching is a powerful mechanism that stores the state of each instrument attribute in software. When a function attempts to set the value of one of those attributes, IVI checks whether the new value being passed is different from the value already set in the cache. Only then will it send the command to the instrument.

This technique saves a considerable amount of unnecessary bus I/O, which is extremely important, particularly when instruments are connected through relatively slow buses such as serial buses or GPIB (General Purpose Interface Bus; also referred to as the IEEE-488 bus).

Range checking is a feature with which developers can use to test whether the values of a program are set within valid ranges.

With interchangeability checking, you can determine whether your system is optimized for exchanging instruments. For example, if the program calls a measurement function without first configuring the measurement type, IVI produces an interchangeability warning.

Dealing With Defaults
Return to Top

The reason for that is the program assumes that, by default, the instrument is set up for a certain type of measurement, such as DC voltage. While this might be the case for the instrument presently used, it might not be for an instrument that replaces it in the future--which might make resistance measurements by default. This means that the program would behave differently; hence, the interchangeability warning.

Spying is a mechanism by which a developer can view every instrument function that the driver sends, and determine whether that function executed properly, returned an error, or returned an interchangeability warning.

All of these features are designed to simplify development and increase productivity, and can be turned off when a system is deployed, in order to optimize performance.

To find out more about IVI, visit http://www.ni.com/ivi and http://www.ivifoundation.org.
Click here to get your listing up.

Copyright © 2003 ChipCenter-QuestLink
About ChipCenter-Questlink  Contact Us  Privacy Statement   Advertising Information  FAQ