Writing an IVI Driver

By Vijay Malhotra,

Contents

Instrument drivers have emerged as a key development tool for automated test developers, but engineers must first learn how to create them. The first article in this three-part series, How to Develop IVI Drivers describes the high level functions that are used to program an instrument and thereby allow developers to focus on developing test functions, rather than learning the details associated with programming an individual instrument. The part also reviews the test system developer requirements, shows how IVI builds on top of standards established by various industry groups, such as VXIplug&play, IEEE, and SCPI. And finally it describes how IVI drivers are based on instrument attribute models defined by IVI Foundation

As a result of using instrument drivers, test functions become easier to develop, maintain and update because test code does not get littered with the command strings required to program a particular instrument. But how can you write your own IVI drivers? This part covers the steps necessary to write your own IVI drivers. It provides the first five steps needed to create a driver.

Writing IVI Drivers
IVI drivers can be developed in any environment capable of generating 32 bit DLLs (or shared object libraries on the Sun Solaris platform). However, they are most easily built in LabWindows/CVI since the package includes many tools that help in the development of drivers. These include an automated development wizard that creates a template containing the majority of the driver code, and navigation tools that make it easy to develop and test sections of driver code.

There are several steps involved with creating a driver. The first and perhaps most obvious, is to familiarize yourself with the command set of the instrument you are writing a driver for, and to determine which instrument category that most adequately describes its functionality. The following sections will examine the process of writing a driver for an ACME incorporated model XYZ 2-channel digitizer/spectrum analyzer with the specifications shown in Figure 1.

Return to Contents

Step One—Create a Driver Template

LabWindows/CVI has a wizard built into it that automates much of the driver development process. The wizard is launched via the Tools menu and prompts the driver developer to enter information through a series of dialog boxes and proceeds to create a code template based on this information. Some of the wizard dialogs along with a brief explanation of the parameters are shown in Figures 2, 3, 4, and 5

Note: The IVI Foundation is currently reviewing specifications for spectrum analyzers and several other instrument categories. A spectrum analyzer template may be better suited for the ACME XYZ.

The wizard automatically creates a code template, function panels and a function tree based on the information you enter in the dialog boxes. The code template contains extensive modification instructions and examples for implementing various attributes. The function panels contain documentation for each of the functions, controls and indicators. A function tree (Figure 4) and an attribute editor (Figure 5) provide convenient mechanisms for navigating through and completing various portions of the instrument driver.

Click here to see Figure 4.

Click here to see Figure 5.

Return to Contents

Step 2—Remove Unused Extensions

The IVI Foundation specifications define Fundamental and Extension attributes and functions. The fundamental attributes and functions represent functionality that is common to 80-95 percent of instruments in a category and have to be implemented in order for a driver to be IVI-compliant. Extensions are functions and attributes that represent more specialized features of an instrument class and do not need to be implemented if an instrument does not support them. Examples of fundamental capabilities for an oscilloscope include functions and attributes for configuring the horizontal and vertical sub-systems. Triggering functions and attributes provide an example of extended capabilities. Although all oscilloscopes have very similar fundamental capabilities for vertical and horizontal settings, there is a wide variety of trigger modes across oscilloscopes. The IVI Foundation specification for oscilloscopes includes extensions for different scope trigger modes, such as video triggers, runt trigger, width ter, and so on.

In this situation the ACME XYZ Scope only supports edge triggering and all functions and attributes that relate to other triggering mechanisms need to be removed from the driver code and header files.

Return to Contents

Step Three—Identify Independent Attributes

An independent attribute is one that is not affected by any other attribute setting. Acquisition type, probe attenuation, vertical coupling, input impedance, trigger type, trigger coupling and trigger slopes are examples of independent oscilloscope attributes.

Return to Contents

Step Four—Complete the attribute callbacks for the attributes identified above

Consider the acquisition type attribute as an example. The ACME XYZ digitizer supports normal, peak detect, envelope detect, spectrum analyzer and hi-resolution modes.

Table 1. Command Strings used to configure and query the ACME XYZ acquisition mode

The attribute editor is used to edit range tables (Figure 6)and command strings (or register values) for setting and retrieving a hardware attribute. A range table provides a simple and convenient mechanism for storing valid hardware settings, and is one of the many approaches available for implementing range checking.

Once the range tables are completed, you need to complete the Write and Read callbacks. The Write callback is used to actually set the value of the hardware attribute and is always called if state caching is turned off. When state caching and range checking are on, the IVI engine does not execute the write callback unless the following two conditions are met:

1. The value you are trying to set is a valid value for the attribute.
2. The cached value is not valid or you are setting the attribute value to something other than the cached value.

The read callback is similar to the write callback but is used to retrieve attribute settings. It is always executed if state caching is turned off. The read callback only executes when the state of an attribute is required and it is not stored in memory (i.e. is not cached).

Return to Contents

Step Five—Specify attribute invalidation rules

The IVI engine uses a relatively straightforward mechanism to maintain the integrity of the state cache.

Among the many techniques it relies on are attribute invalidation lists which are used to resolve high-level attribute dependencies. In many cases, the value of an attribute may be affected by the value of another attribute. For example, an oscilloscope's vertical range and offset depend on the probe attenuation applied to the input signal. Changing the probe attenuation changes both vertical range and vertical offset. This means that the cached values for vertical range and offset need to either be invalidated or updated whenever the probe attenuation changes. Invalidation is easily accomplished by including vertical range and vertical offset in the attribute invalidation list (Figure 7) for the probe attenuation attribute.

Other, more advanced techniques exist for maintaining the integrity of the state cache. These include:

1. Invalidate an attribute programmatically. The rules that specify when to invalidate such an attribute may be too complex to specify via an attribute invalidation list and so IVI provides functions such as Ivi_InvalidateAttribute and Ivi_InvalidateAllAttribute to programmatically invalidate attributes
2. Update the cache programmatically. It may be possible to predict how changes in one attribute affect other attribute values. In such cases, it makes sense to update, rather than to invalidate the affected attributes. The instrument driver does not need to perform instrument I/O to get the value for an attribute if it is stored in the cache. IVI provides options flags such as IVI_VAL_DONT_MARK_AS_SET_BY_USER and IVI_VAL_SET_CACHE_ONLY that are useful for updating the cached attribute values
3. Specify that the instrument coerces value is in a consistent, but unknown fashion (i.e. every time you send the instrument the value X it coerces it to Y, but I can't figure out the algorithm used to make that conversion). The IVI architecture implements a very flexible caching mechanism using the flag IVI_VAL_COERCED_BY_INSTRUMENT_ONLY to handle this situation and to maintain most of the benefits associated with state caching. When you set this flag, the IVI engine stores the value you tried to set. When you set the attribute again, the engine checks to see if the value you are setting differs from this value before proceeding.
4. Disable state caching for the attribute. IVI allows you to set the IVI_VAL_NEVER_CACHE flag to completely disable caching on an attribute. This may be useful when dealing with attributes that coerce values in a completely unknown method, or for which the dependency of attribute values cannot be determined
5. Disable state caching for the entire driver. For very complex, ill-behaved instruments that do not follow any correlation between the values you send them and the internal values that are stored, state-caching can be disabled for the entire driver.

Note: Examples 3,4 and 5 represent very difficult instrument programming examples and instruments that fall in these categories are not only difficult to cache values for, but are also hard to program in general because of their inconsistent and poorly documented behavior. Nevertheless, the possibility of encountering such badly designed instruments exists, and IVI can handle these situations using the described flexible options.

Author's Biography
Vijay Malhotra is an Application Engineer at . His job responsibilities include helping customers resolve problems, developing and teaching course material, writing articles and application notes, and developing demos. He joined in September 1996. Malhotra was previously a Control Systems and Automation Engineer at Jet Process Corporation, where he was responsible for selecting and integrating motion control systems, PLCs, and various computer-based measurement and automation systems for use in a semiconductor vapor deposition process. Malhotra holds a MSEE from Cornell University and a BSEE (magna cum laude) from Case Western Reserve University. , 11500 North Mopac Expressway, Austin, TX 78759. Phone: 512-794-0100.

Return to Contents