Using IVI Drivers in LabVIEW

Publish Date: Jan 27, 2012 | 6 Ratings | 3.67 out of 5 | Print | 2 Customer Reviews | Submit your review

Overview

This document is intended for LabVIEW test developers who are familiar with traditional VXIplug&play instrument drivers but want to migrate to the IVI drivers.

Table of Contents

  1. Introduction
  2. IVI Benefits and Features
  3. Using IVI Features
  4. Using Measurement & Automation Explorer to Configure IVI
  5. Differences with Traditional Drivers
  6. Conclusion
  7. Related Links
  8. Bibliography

1. Introduction

Instrument drivers—software modules that control programmable instruments—have advanced technologically in many ways. Standardization of hardware interfaces, including the standardization of GPIB through the IEEE 488.1 and 488.2 standards, has led to continual improvement of instrument driver technologies. The VXIplug&play Systems Alliance introduced VXIplug&play instrument drivers, which standardized naming conventions, file formats, and distribution of drivers. IVI (Interchangeable Virtual Instruments) drivers are the result of the efforts of the IVI Foundation, a consortium of instrument vendors, systems integrators, and end users who have a common interest in further improving the quality and performance of instrument drivers. For more information on the IVI Foundation, visit the IVI Foundation Web site at http://www.ivifoundation.org.
This document briefly covers the IVI features, explains how to access the features in LabVIEW, and lists the visible differences between IVI and traditional drivers. You should know basic GPIB, serial and/or VXI concepts, and how to operate LabVIEW to develop test applications with traditional drivers based on the VISA VIs. This document focuses on IVI instrument specific drivers, not on IVI class drivers.

For additional information on IVI class drivers, which enable you to develop hardware-independent applications, refer to Application Note 121, Using IVI Drivers to Build Hardware-Independent Test Systems with LabVIEW and LabWindows/CVI.

Back to Top

2. IVI Benefits and Features


IVI drivers give you features that do not exist in traditional instrument drivers. This section describes the following IVI benefits and features:

  • Standardized configuration utility
  • Standardization
  • State caching
  • Range checking
  • Simulation
  • Status checking
  • Coercion recording


The Using IVI Drivers section describes two methods that you can use to access the IVI driver features.

Standardized Configuration Utility

You can configure IVI drivers settings independently of a test application. With the IVI component of Measurement & Automation Explorer (MAX), you can set up driver session for instrument driver settings that an application can use. Instead of using a standard VISA resource name string, such as GPIB::2::INSTR, you can pass a previously configured driver session or logical name such as SCOPE1. The IVI Engine uses the predefined settings associated with the resource name string SCOPE1 for the test application. This virtual approach allows you to set up a number of different instrument driver configurations that test applications can easily access using the resource name string. To learn more about IVI configuration in MAX, refer to the DevZone document, Using Measurement & Automation Explorer to Configure IVI. You can access this document at http://ni.com/zone.

Standardization

The IVI specifications are supersets of the VXIplug&play standards for driver development. IVI addresses areas that the VXIplug&play standard does not include. The VXIplug&play Systems Alliance standardizes design requirements with the VXIplug&play driver standard, including some naming convention, data format, and driver distribution standards. These traditional VXIplug&play drivers emphasize ease of use, and they do not set guidelines for the internal structure of drivers or for the interface provided for similar instruments.

The IVI class specification:

  • Sets internal structure
  • Sets programmatic interface of similar instruments
  • Divides instruments into functional classes such as oscilloscopes and digital multimeters
  • Establishes the characteristics of each class of instruments


The IVI Foundation also specifies the programmatic interface for these different classes of instruments. For example, with IVI all function generator drivers have the same programmatic interface for basic instrument functionality.

With IVI, two drivers for function generators share the same:

  • VI names (with the exception of the prefix)
  • Number of inputs/outputs
  • Terminal pattern
  • Control definitions


The IVI Engine always defines measurement parameters consistently, and the instrument driver adjusts parameters to account for differences between individual instruments. For example, the output amplitude for the two function generators is always defined to be volts peak-to-peak, not volts peak or volts rms. Although the interface to each driver VI is the same, IVI customizes the underlying operation of each function in the driver for the specific instrument. By defining standards for each of these functions, IVI makes it possible for you to develop test programs that can work with any function generator. When you have a standard interface to instrument drivers, you can work more quickly because you do not need to learn a new interface for each new instrument.

Standardization does not restrict your ability to access individual or unique capabilities of a specific instrument. Instrument specific VIs supplement the standard VIs and provide access to functions that are unique to the instrument. Standardization in IVI also enables instrument interchangeability in your test system.

For further information on building test systems that are independent of any particular brand or type of instrument, refer to Application Note 121, Using IVI Drivers to Build Hardware-Independent Test Systems with LabVIEW and LabWindows/CVI.

State Caching

IVI drivers maintain the physical state of instruments in a software cache to increase the efficiency and speed of instrument drivers. Focusing on the ease of use, traditional instrument drivers did not always provide optimal performance. With those drivers, high-level VIs might combine a number of instrument settings into a single VI. Calls to these high-level VIs often result in transmission of redundant commands to the instrument. In contrast, IVI drivers use state caching to eliminate redundant commands.

In IVI drivers, an attribute represents each area that you can configure in an instrument. High-level driver VIs logically group a number of attributes together. Consider the Configure Standard Waveform VI illustrated in Figure 1. The VI configures the parameters for a function generator and sets the waveform shape, amplitude, offset, frequency, and start phase for a waveform. When the VI performs a frequency sweep, only the frequency parameter changes. It is redundant to send the other four settings each time you run the VI. With state caching, only the frequency parameter is sent to the instrument each time you run the VI.


Figure 1. Configure Standard Waveform VI



The key to state management in IVI drivers is the IVI Engine, which controls the reading and writing of attributes to and from instruments. Through state caching, the IVI Engine stores a copy of the current instrument setting of each attribute, performing I/O with an instrument only when an attribute's value changes.

For more information on how the IVI Engine manages state caching, refer to Application Note 122, Improving Test Performance through Instrument Driver State Management.

Range Checking

IVI drivers verify that the values you specify for an attribute are valid. Previous LabVIEW drivers indicated the valid ranges for settings indirectly through the online documentation for each control. IVI drivers provide this information and verify the entries you have made if you enable Range Checking. Range checking is enabled by default, but you can disable it after you debug your application in order to increase execution speed.

If you enter an incorrect value, IVI drivers return an error through the error out indicator. Error checking includes consideration of rounding performed by specific instruments. To reduce any discrepancies, the driver coerces or rounds values to the actual value that the instrument uses internally. When you specify an attribute value, IVI drivers also identify dependencies for the attribute ranges on other instrument settings. For example, the vertical range (in volts per division) for an oscilloscope channel is dependent on the attenuation of the probe that you are using. When calculating the valid vertical range, IVI oscilloscope drivers take into account the attenuation of the probe. The IVI Engine uses this dynamically-calculated range to verify the setting. This approach to range checking eliminates incorrect settings and points out conflicts in an application.

Simulation

Unlike traditional drivers, IVI drivers have a simulation mode in which you can make calls to the driver without being connected to an instrument. Simulation mode provides the benefits shown in Table 1.


Table 1. Characteristics of Simulation Mode for IVI Drivers
Simulation Mode Characteristics
Purpose
Provides an instrument handle that VIs in the driver can use. To eliminate run-time errors that invalid instrument handles cause.
Does not alter any other behavior in driver operation. For example, range checking occurs as it does when a physical instrument is present. To verify the values you are planning to send the instrument, while you develop the test application.

To test a new instrument feature before you purchase that instrument by installing its IVI driver and running a test program to ensure that the instrument provides the functionality that you want.
Lets you simulate the data that you normally acquire using built-in algorithms to simulate data generation. To test your application with realistic data.

For more information on simulation, refer to Application Note 120, Using IVI Drivers to Simulate Your Instrumentation Hardware in LabVIEW and LabWindows/CVI.

Status Checking

Traditional LabVIEW drivers provide error query VIs that a programmer uses to check the status of instruments. This technique burdens you with inserting error-query VIs throughout the application to verify operation at various stages. With IVI drivers, you can check the status of an instrument after every function that interacts with the instrument without adding extra VI calls. Status checking in IVI drivers is enabled by default so that you can verify your applications during development. After the application has been thoroughly tested and verified, you can disable status checking to improve performance.

The IVI Engine checks the status of an instrument only after a function writes an attribute to, or reads a value from, an instrument. If an instrument error occurs at that time, the IVI Engine returns an error through the error out control. The developer can conditionally call the error query VI to learn more details about the instrument-specific error. An error reported from status checking does not invalidate the cached state of the instrument.

Coercion Recording

Often you choose an instrument setting from a range of values (for example from 1.0 to 1000.0) and the instrument coerces the value to one of several selected values. A digital multimeter (DMM) instrument might accept a value from 1.0 to 1000.0, and the DMM would coerce that value to one of three maximum reading ranges: 10.0, 100.0, or 1000.0. In this DMM example, if you set the range to 50.0, the instrument would coerce the value to 100.0.

To make state caching work properly, the IVI Engine must store the coerced value in the cache. Therefore, instead of letting the instrument coerce the value, the IVI driver coerces the value before it sets the instrument.

If you want to track the coercions that the IVI Engine performs, you can enable Record Value Coercions. Record Value Coercions maintains a list of all coercions for Integer and Real values passed to the instrument driver VIs. You can call the Get Next Coercion Record VI, which accesses the coercions by retrieving and clearing the oldest recorded instance.


CAUTION: If you enable Record Value Coercions and never use Get Next Coercion Record VI to retrieve and clear those coercion records, the records build up and could eventually overflow your computer memory.

Back to Top

3. Using IVI Features


In most cases, you develop a test application with the IVI driver VIs in the same way that you develop a test application with traditional LabVIEW drivers. Like traditional LabVIEW driver VIs, IVI driver VIs are grouped together in functional areas that you combine into an application. Unlike traditional LabVIEW driver VIs, IVI driver VIs operate differently internally since they rely on the IVI Engine to coordinate and control the features as described in the IVI Features section. For this reason, IVI drivers communicate with instruments and the IVI Engine through DLLs (dynamic link libraries).

The internal differences between traditional drivers and IVI drivers should not affect your use of driver VIs to develop an application. After you configure the IVI driver with the IVI features you want (state caching, range checking, simulation, status checking, or recording coercions) you continue developing an application as you do with a traditional LabVIEW instrument driver.

You can configure the IVI features using one of the following options:

  • Initialize With Options VI
  • Driver Session that you set up with MAX



The Initialize with Options VI

IVI drivers include two distinct initialization VIs. The first performs similar to the Initialization VI found in traditional drivers and the second is the Initialize With Options VI. Figure 2 shows a sample front panel for the Initialize with Options VI. The only difference between the Initialize with Options VI and the Initialize VI of a traditional driver is the option string. The option string configures the IVI driver features that you choose: state caching, range checking, simulation, status checking, and record value coercions. For instrument drivers that support a family of instruments, you can also use the option string to set the particular model of instrument that you want the driver to emulate.



Figure 2. Sample Front Panel for IVI Initialize with Options VI


To enable one of the IVI features, you set its value to 1 in the option string. To disable a feature, you set its value to 0. The IVI Engine uses these settings when it runs your test application. The following table lists IVI driver features, their corresponding strings for the option string, and the default value setting for each feature. The IVI Engine uses the default value listed below whenever you do not name a feature in the option string.



Table 2. Option Strings for IVI Features


Feature
Option String
Default Value
Default State
State Caching
Cache
1
Enabled
Range Checking
RangeCheck
1
Enabled
Simulation
Simulate
0
Disabled
Status Checking
QueryInstrStatus
1
Enabled
Record Value Coercions
RecordCoercions
0
Disabled

The option string in Figure 2, Simulate=0,RangeCheck=1,QueryInstrStatus=1,Cache=1, results in the following configuration:

  • Instrument simulation is disabled.
  • Range checking is enabled.
  • Status checking is enabled.
  • State caching is enabled.
  • Recording of coercions of values is disabled.

    Back to Top

    4. Using Measurement & Automation Explorer to Configure IVI

NOTE: This section discusses MAX. The IVI component for MAX comes with the IVI Compliance Package.


Instead of using the Initialize with Options VI, you can easily and conveniently enable and disable IVI features in MAX. The IVI configuration utility in MAX configures a driver session to store the settings you want to use. This method uses the standard Initialize VI that you use with traditional LabVIEW drivers. To make your program use the configured settings, you pass the name of the configured driver session to the resource name control of the Initialize VI. For example, if an oscilloscope is connected to your PC through the GPIB bus with an address of 2, you can use either of the following approaches:

  • As with any traditional driver, you can enter GPIB::2::INSTR for the resource name. When you use this approach, MAX settings do not take effect.
  • Alternatively, you can enter a driver session that you associate with your oscilloscope as the resource name string.


NOTE: The settings you make through MAX could conflict with settings you make with the Initialize With Options VI. Therefore, you will generate errors if you attempt to use both approaches. Make sure the option string is empty when you use the MAX approach.

 

Consider the following example. If you previously configured the fl45 driver session for a Fluke 45 Digital Multimeter, you can set and use the Initialize VI of the specific driver. Simply replace the resource name string with fl45. Figure 3 illustrates this configuration. The IVI Engine then uses the configuration parameters associated with the fl45 driver session when it executes your application.


Figure 3. Using a Virtual Instrument Name to Initialize Driver Settings



In the IVI Drivers subfolder of MAX, you find the driver sessions that you can configure. Along with driver sessions, you also see the subfolder for Logical Names. You can use Logical Names at class-driver level and can also be used at the specific-driver level. They point to driver sessions and allow for interchangeability. Driver Sessions consist of an instrument driver software module, general property settings, and, when you are not in simulation mode, a hardware asset. Instrument drivers specify the instrument driver DLL while the hardware asset properties specify the resource name to access a physical device. To learn more about IVI configuration in MAX, refer to DevZone document, Using Measurement & Automation Explorer to Configure IVI. You can access this document at http://zone.ni.com/devzone/cda/tut/p/id/4594.

Back to Top

5. Differences with Traditional Drivers


This section addresses some of the changes that you will notice with IVI drivers if you are familiar with traditional LabVIEW drivers.

NOTE: VIs in LabVIEW and function panels in LabWindows/CVI can be run interactively. Therefore, if you are unfamiliar with instrument drivers, a particular function, or just want to test various values, you can run the function by clicking on the run button (white arrow).

VISA Sessions versus Instrument Handles

In most traditional LabVIEW drivers, a VISA session serves as an identifier for communication with GPIB, serial, and VXI instruments; you create a VISA session when you initiate communication with an instrument, and you close the session when you end communication. Your application passes a VISA session between VIs.

In IVI drivers, an instrument handle serves as the identifier. You create this instrument handle in one of your initialize functions. Instead of passing VISA sessions between VIs, your application passes the instrument handle from VI to VI.

New VIs

A few new VIs exist for IVI drivers that do not exist for traditional instrument drivers.

  • Initialize with Options VI- Discussed previously in this document, this VI is identical to the Initialize VI except for the addition of the option string control. You use the option string to configure the inherent settings of the driver, such as simulation and range checking.
  • Get Next Coercion Record VI- Tracks input values that the IVI driver coerces to new values. Get Next Coercion Record VI returns and clears coercions, if any, when you enable Record Coercions.


CAUTION: If you enable Record Value Coercions and never use Get Next Coercion Record VI to retrieve and clear those coercion records, the records build up and could eventually overflow your computer memory.


Virtual Channel Names

When using traditional instrument drivers, you have to supply some functions with the name of the channel that you would like to configure or measure. It is the same way with IVI drivers, unless you want to take advantage of the interchangeability that IVI offers. To enable interchangeability, you must configure IVI in MAX and use virtual channel names. Virtual channel names are simply aliases for specific driver channel names. This configuration enables the class drivers to use virtual channel names to make calls to a specific driver regardless of the specific driver's channel name style. You set up virtual channel names in the properties of a driver session. For more information on setting up virtual channel names, refer to the DevZone document, Using Measurement & Automation Explorer to Configure IVI. You can access this document at http://ni.com/zone. You may also refer to channels when using specific drivers by using virtual channel names.


NOTE: When using class drivers and switching between a multichannel instrument and a single-channel instrument, for issues of interchangeability, always pass a virtual channel name even if the instrument has only one channel.

IVI Class Drivers

Class drivers are what enable IVI drivers to be interchangeable. When you make calls to a class driver, the class driver then calls the specific driver to perform its function. The class driver knows which specific instrument driver to call and what attributes to call when you configure a logical name in MAX and pass it to the class driver's Initialize VI. For more information on setting up logical names, refer to the DevZone document, Using Measurement & Automation Explorer to Configure IVI. You can access this document at http://ni.com/zone.

You can get IVI class drivers for free when you download the NI IVI Compliance Package from http://www.ni.com/ivi. For additional information on IVI class drivers, which enable you to develop hardware-independent applications, please refer to Application Note 121, Using IVI Drivers to Build Hardware-Independent Test Systems with LabVIEW and LabWindows/CVI.

Back to Top

6. Conclusion


Instrument drivers are an indispensable tool to help you rapidly develop test and measurement applications. By providing high-level VIs for programming, they eliminate the need for application developers to learn complex programming protocols. The new technologies introduced with IVI drivers maintain the benefits of traditional drivers while adding features that improve the application development process and application performance. Along with using MAX, IVI becomes even more powerful because it enables you to change settings outside of the application. You should develop an application with IVI instrument drivers in the same way that you develop applications with traditional LabVIEW drivers, except that you can also take advantage of the new IVI features described in this.

Back to Top

7. Related Links


On-Demand Training: IVI Fundamentals I - What Are IVI Drivers? (SSP required)

On-Demand Training: IVI Fundamentals II - Why Use IVI Drivers? (SSP required)

Back to Top

8. Bibliography


National Instruments, LabWindows/CVI Instrument Driver Developers Guide, National Instruments Corporation, Austin, 1999.

Noel Adorno, Application Note 111 - LabVIEW Instrument Driver Standards, National Instruments Corporation, Austin, 1998.

John Pasquarette, Application Note 120 - Using IVI Drivers to Simulate Your Instrumentation Hardware in LabVIEW and LabWindows/CVI, National Instruments Corporation, Austin, 1998.

John Pasquarette, Application Note 121 - Using IVI Drivers to Build Hardware-Independent Test Systems with LabVIEW and LabWindows/CVI, National Instruments Corporation, Austin, 1998.

John Pasquarette, Application Note 122 - Improving Test Performance through Instrument Driver State Management, National Instruments Corporation, Austin, 1998.

Back to Top

Customer Reviews
2 Reviews | Submit your review

Cannot Impliment  - Sep 25, 2006

This app note cannot be implimented because the version of MAX referenced is obsolete.

  - Sep 15, 2005

This is based on an older version of MAX (which is not even mentioned). While the document is well-structured, it doesn't help me much since the new MAX is quite different.

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit