Developing an IVI Driver for a Series of Instruments

This document explains how to:
• Choose between developing one family driver or multiple individual drivers for a series of instruments
• Develop a family driver

This document assumes that readers are familiar with basic IVI driver development and are using LabWindows/CVI and the IVI Class Templates.

Choosing Between a Family Driver or Multiple Individual Drivers

A family driver supports multiple models from a series of instruments.  The instrument driver that supports the entire series of Tektronix TDS 200 oscilloscopes including the TDS 210, 220, and 224 is an example of a family instrument driver.

 To develop an IVI driver for a series of instruments, decide whether to write one family driver that functions for the entire series or to write separate drivers for each model in the series. Instruments with similar model numbers do not always have similar features.  Base your choice primarily on an analysis of the similarity of the instruments.

The following examples describe the two options.

The Keithley 2300 Series Power Supplies

The Keithley 2300 series power supplies divides into two distinct subsets: the battery/charger simulators (2302 and 2306), and the DC power supplies (2303x and 2304A).  Their different features sets are designed for different types of users. For example:

• The battery/charger simulators support configuration of instrument specific voltage protection, output bandwidth, and channel output impedance—the DC power supplies do not.
• The battery/charger simulators support step pulse current measurement—the DC power supplies do not.

Due to these different features, two separate drivers, the ke230x and the ke230y, provide the most efficient solution.

The Tektronix TDS 200 Series Oscilloscopes

The Tektronix TDS 200 series oscilloscopes, on the other hand, are very similar to each other from an instrument  driver developer's perspective. The developer can handle minor differences with conditional statements. For example:

• All models support configuration of some math functions—the only difference is the valid range of math functions.
• All models have channels—the only difference is the number of channels.

Due to the lack of significant differences, one family driver, the tktds2x0, provides the most efficient solution.

Developing a Family Driver

Determining Instrument Models

A family driver requires the instrument model in order to correctly communicate with different models and provide different functionality. A family driver can determine the instrument model by two methods: ID Query and Driver Setup Option.

ID Query — If you turn the ID query parameter of the Initialize function on, and the user does not run the driver in simulation mode, the driver performs an ID query at initialization. The driver sends an ID query command (for example, *IDN?) to the instrument and receives an ID query response string (for example, Manufacturer, Model, Firmware Revision) from the instrument. The driver can extract the model number from this string.

Driver Setup Option — The user can specify the instrument model they want to use in the driver setup tag in the option string parameter of the prefix_InitWithOptions function.

Specify the driver setup option in the following format:

DriverSetup = Tag1:Value1; Tag2:Value2

In the driver you can define Model as a valid tag and instrument model strings as valid values of this tag. The user can then specify the instrument model in the following format:

DriverSetup = Model:M1

The driver can extract the instrument model from the option string. The driver setup option should always override the ID query.

Initializing Attributes

Once the driver has determined the instrument model, it can initialize the attributes. Pass the instrument model as a parameter to the prefix_InitAttributes function. You can change the prototype of prefix_InitAttributes because it is a non-exported function. The prefix_InitAttributes function initializes the attributes based on this information.

Notice that directly modifying the Ivi_AddAttribute calls in the prefix_InitAttributes function may cause the attribute editor to stop working. For example, if you have multiple Ivi_AddAttribute calls for the same attribute (within different conditions in a conditional statement), the attribute editor does not work. To ensure that the attribute editor works, leave the Ivi_AddAttribute calls unchanged (for example, initialize the attributes with some arbitrary settings), and at the end of the prefix_InitAttributes function, pass the instrument model to a utility function that selects the appropriate settings.

Checking Errors After Initialization

After initialization, the driver has already determined the model of the instrument along with the corresponding supported functions, attributes, and attribute values. If the user tries to access a function, an attribute, or use a value that is not supported by the specific model, the instrument driver returns an error.

Since the prefix_InitAttributes function adds the unsupported attributes with the IVI_VAL_NOT_SUPPORTED flag, the IVI Engine generates an error when the user tries to access unsupported functions either directly or by calling an unsupported function that accesses them.

However, if the user tries to call an unsupported function that does not access an unsupported attribute (for example, non-configuration functions), errors are not returned automatically. In this case, the driver has to check the instrument model. You can store the instrument model information in a hidden attribute at initialization so that in functions that depend on the instrument model you can verify validity of the instrument model for the function by accessing that hidden attribute.

Documenting the Driver

After handling the instrument model in the source code, document the family driver.

In the header file, specify what models the driver supports in the PREFIX_SUPPORTED_INSTRUMENT_MODELS attribute.

Document all the functions and attributes that depend on the model in the .fp and .sub files. For example, document the driver setup option format for different models in the option string control of the prefix_InitWithOptions function in the .fp file. If the behavior or valid range of a parameter in a function or an attribute varies for different models, explicitly list the variations for each of the supported models in the .fp or .sub file. Similarly, if a function or an attribute is valid only for some models, you must specify that in the .fp or .sub file. If the driver has a significant number of functions or attributes that are valid only for some models, you should change the function hierarchy in the .fp file or the attribute hierarchy in the .sub file to group them under a separate class.

Naming the Driver

Give the family driver an appropriate name. In general, use x to represent the varying digits in the series, such as tktds2x0. If x is used for another driver, use y instead, such as ke230x and ke230y.

Handling Instrument Options

Some instruments have optional modules that provide additional features. You can handle this situation in a similar manner to instrument models. You can determine the instrument option through ID query or by defining a tag in the driver setup option for users to specify what instrument option they want. You can initialize attributes, check for errors, and write documentation based on this information.

Reader Comments | Submit a comment »