Product/Service

Finalize and Test IVI Drivers

This part helps you complete the remaining driver attributes, add any specific functions, edit the driver information, and lastly, test the driver.
N/Aalhotra, <%=company%>

Contents

•Introduction
•Step 6: Complete remaining attributes
•Step 7: Add instrument specific functions and attributes
•Step 8: Edit the instrument diver function panels and driver documentation
•Step 9: Test the driver
•Summary of Driver Development Process
•Summary

Introduction

Instrument drivers have emerged as a key development tool for automated test developers. How to Develop IVI Drivers describes the high level functions 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. It 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? Write an IVI Driver covers five steps necessary to write your IVI drivers. It tells you what you need to create a driver, identify attributes and specify the attribute rules. This part helps you complete the remaining driver attributes, add any specific functions, edit the driver information, and lastly, test the driver.

Contents

Step 6: Complete remaining attributes.

The valid range settings for many attributes depend on the value of other attributes. For example, the number of points that the ACME XYZ scope can acquire depends on the acquisition mode and acquisition type. As another example, vertical range depends on probe attenuation. IVI provides several advanced approaches to implementing range checking and so on for these more advanced situations.

  1. Implement a Range Table Callback (Table 1). A range table callback is used to select a range table and is useful when you have a small number of different possible range settings. Examples of where range table callbacks are useful include the measurement range attribute on a DMM and horizontal record length on the ACME XYZ scope.

    The ACME XYZ scope has three possible combinations for horizontal record length settings. Each combination is stored in a coerced range table and the range table callback determines which combination to use based on the acquisition mode and acquisition type. Each coerced range table stores all of the horizontal record length values that are valid for a particular combination

  2. The ACME XYZ scope accepts values that are a power of two for record length. While it is acceptable to completely specify the contents of each range table as outlined above, it is inefficient to do so since a simple relationship exists between the valid settings. Another, more efficient approach, is to use a Coerce Callback (Table 2 and Figure 1) in conjunction with a range table callback. When using a coerce callback, the range tables only need to store the upper and lower limits that are valid for a particular configuration setting. The coerce callback is then responsible for coercing any values to a setting that is valid for the instrument.

  3. Click here to see Figure 1.

    Specify your own range checking mechanism via a Range Check Callback (Figure 2). The IVI engine uses a default check callback for all attributes that have range tables associated with them. You can extend this range checking mechanism by specifying your own range-checking algorithm to handle situations where it is more efficient to determine valid range settings during program execution. Consider the Vertical Range attribute on an oscilloscope as an example. The valid vertical range settings depend on the probe attenuation. Some scopes, such as the ACME XYZ, support a large number of probe attenuations and a driver that used a range table callback would require a range table for vertical range and vertical offset for each probe attenuation. This can be painstaking to implement due to the large number of range tables involved, and Range Check callbacks provide an alternative implementation strategy. In the case of vertical range, a range check callback is used to adjust the desired vertical range setting to the equivalent setting for a unity gain probe. This adjusted value is then checked against a range table containing vertical range settings valid with a unity gain probe. The ACME digitizer's Horizontal Record Length attribute also benefits from a range check callback. The valid settings for horizontal record length are affected by the following additional criteria:

    • Two waveforms are required for Envelope and Peak Detect modes- (that is, twice the number of points is required).
    • The number of points allowed per channel depends on the number of enabled channels.

    The following Range Check Callback pseudo code adjusts the desired record length by the number of enabled channels. The record length is also doubled if Peak or Envelope modes are used and then a Default Check callback is used to compare the adjusted value against entries stored in a range table.

Contents

Step 7: Add instrument specific functions and attributes

IVI allows you to implement attributes and functions for the features that are unique to your instrument (that is, functions and attributes not contained in the class specifications - see Table 3). You can still take advantage of state caching, range checking, and so on when you implement unique functions and attributes. The ACME XYZ digitizer contains the functionality of a basic spectrum analyzer. The user can configure the ACME XYZ to perform FFT analysis and can also specify they type and nature of filter and window used to process data. The following unique attributes and functions should be added to the XYZ driver to implement this functionality.

Contents

Step 8: Edit the instrument diver function panels and driver documentation.

One of the final steps in creating a driver is the process of documenting its functionality.

The LabWindows/CVI instrument driver wizard automatically generates function panels that include controls, indicators and documentation that is generic to the type of instrument created a driver for. These function panels need to be edited to reflect the capabilities for the specific instrument you are using.

Consider for example, the function ACMEXYZ_ConfigureAcquisitionMode, used to configure the acquisition mode on the ACME XYZ digitizer. The wizard generated function panel and documentation need to be edited to reflect the fact that the XYZ supports Normal, Peak Detect, Envelope and Spectrum Analyzer acquisition modes.

Contents

Step 9: Test the driver

Before releasing your driver, you should test it to make sure that it behaves correctly when various configuration options such as simulation, caching, and so on are enable and disabled. In addition, you should test your driver using IVI Class Driver function calls to make sure that it does not violate any interchangeability issues.

Contents

Summary of Driver Development Process

The process of writing a driver may look intimidating at first. However, the wizard-generated templates contain significant guidelines and examples that are extremely valuable in implementing even the most complex attributes. An oscilloscope's horizontal record length attribute represents one of the most complex attributes to implement correctly. The implementation of this attribute sometimes requires one to use a combination of advanced techniques including Range Table Callbacks, Coerce and Check callbacks. Most instrument attributes are easily implemented using a single range table, or a range table callback for situations where the valid range settings depends on other attribute settings. The following guidelines should be observed for selecting between the various approaches to implementing attributes.

  1. Do the valid Range Settings depend on any other attribute values? If no continue, otherwise go to step 5.
  2. Is the number of possible settings small (say less than 25 values)?If yes, consider creating a range table with the range table editor. If no, go to step 3.
  3. Is there a relationship between the valid attribute settings that can be expressed in a non differential equation? If yes, consider creating a range table that stores the upper and lower limits and using a coerce callback. If not go to step 4.
  4. Can the valid attribute values be determined via an iterative process? If yes, consider creating a range table dynamically during program initialization. This is a technique has not been mentioned before since it is used extremely rarely. If no, go to step 6.
  5. Valid range settings depend on other attributes. Consider using a Range Table Callback if the number of dependencies is small (less than 5 range tables) and if each range table is small. Go to step 6 if this is not the case.
  6. The valid attribute settings depend on several other run time settings or contain too many values to enter into a range table. Consider using a range check callback to perform you own range checking or to extend the default callback. If this still does not help, go to step 7.
  7. You may be working on an attribute similar to horizontal record length; consider combining Range Table, Check and Coerce callbacks. Go to step 8 if you are still stuck.
  8. The instrument is either incredibly complicated, or is poorly designed and/or documented. Set the IVI_VAL_COERCABLE_ONLY_BY_INSTRUMENT flag to true to maintain some of the benefits provided by state caching, or set IVI_VAL_NEVER_CACHE to true to perform never cache the attribute value (that is, always perform instrument I/O). As an absolute last resort, disable caching for the entire driver.

Step 8 represents an extreme case that will rarely be encountered. Figure 3 below illustrates the set attribute process in greater detail and should aid you in understanding the relationship between the various attribute callbacks and range tables.

Click here to see Figure 3.

Contents

Conclusion

IVI drivers satisfy the requirements of the most advanced test system developers and provide significant benefits over traditional driver technologies. In particular, IVI drivers provide a high-performance state-caching architecture in addition to several other configuration options that are valuable during the test program development cycle.

Developing an IVI driver requires that you posses some understanding of an instruments behavior and functionality in order to maximize the benefits associated with state caching and range checking. Several options are available to handle situations where this may not be the case.

LabWindows/CVI integrates automated driver development tools that significantly reduce the coding effort associated with writing IVI drivers. Using these tools, it is possible to develop an IVI driver for an instrument for which a class template exists in approximately the same amount of time that it takes to develop a traditional VXIplug&play driver for the same instrument. For example, a typical IVI switch driver may take 2 weeks to develop (including documentation). On the other extreme, a driver for a CDMA analyzer may take 3-6 months to develop due to the complexity associated with such instruments combined with the fact that no IVI Foundation class templates exist.

Author's Biography N/Aalhotra is an Application Engineer at <%=company%>. His job responsibilities include helping customers resolve problems, developing and teaching course material, writing articles and application notes, and developing demos. He joined <%=company%> 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.

<%=company%>, 11500 North Mopac Expressway, Austin, TX 78759. Phone: 512-794-0100.