Improving Test Performance through Instrument Driver State Management

Application Note 122 Improving Test Performance through Instrument Driver State Management Instrument Drivers John Pasquarette With the popularity of test programming tools such as LabVIEW and LabWindows /CVI, instrument drivers have emerged as a key development tool for automated test developers. Through the efforts of the VXIplug&play Systems Alliance, standards for instrument driver naming conventions, file formats, and development frameworks have been agreed on to guarantee interoperability between instrument drivers supplied by instrument vendors. The focus of these instrument drivers is primarily on ease of programming. Instrument drivers provide a high-level programming interface for instruments, replacing low-level GPIB and VXI instrument commands. With these intuitive, high-level functions, test developers can more quickly create modular test programs. Because a driver s primary purpose is to simplify programming, instrument drivers many times do not execute at peak performance for the instrument. The high-level instrument driver functions have a tendency to combine multiple instrument settings and actions into a single function, resulting in time-consuming instrument overhead from redundant reconfiguration and command processing operations. LabWindows/CVI Version 5.0 introduces new instrument driver development tools and technologies to address many of these issues through a new state-management instrument driver architecture. These drivers can be compiled as DLLs and called from LabVIEW, LabWindows/CVI, Visual Basic, Visual C++ or any Windows development tools. Drawbacks and Limitations Due to user demand, many vendors are now providing drivers with their instruments. Users can optimize drivers because vendors deliver them in source code. Thus, users can eliminate code segments that introduce unnecessary overhead in the driver. Although optimizing drivers can speed overall system throughput, this method has some drawbacks. Inexperienced end-users sometimes find it difficult to fully understand driver source code. In addition, instrument vendors have not defined a single format for writing drivers the variations in source code structure and sometimes inconsistent quality can make it difficult for end-users to comprehend and optimize source code for instruments from several vendors. Although VXIplug&play introduced a number of standards for packaging and delivering drivers with their instruments, none of the standards address internal coding practice and structure for drivers. Therefore, even though drivers may appear to be the same on the outside, they are almost always completely different on the inside. As PCs and general-purpose test software tools continue to advance, demand from test developers for more advanced capabilities is increasing. Test engineers are looking to solve very advanced testing requirements with standard, off-the-shelf tools, instead of using the proprietary, expensive, home-grown systems they may have built in the past. In addition, highly competitive industries, such as telecommunications and semiconductor, demand faster and faster testing times to keep up with production. The new, higher-complexity system demands are uncovering many of the drawbacks of the current industry-standard instrument driver architecture. Clearly, it is time for a change. Product and company names are trademarks or trade names of their respective companies. 341522A-01 Copyright 1998 National Instruments Corporation. All rights reserved. June 1998

Objectives of State Drivers The new instrument driver development tools introduced in LabWindows/CVI 5.0 are targeted at solving many of the long-standing limitations with today s instrument driver architecture, as outlined in the following objectives: 1. Improve the run-time performance of drivers without sacrificing ease of use High-level instrument control functions are very intuitive and easy to use when building test programs. Any approach to improving instrument driver performance must not sacrifice this fundamental programming model. State drivers developed in LabWindows/CVI 5.0 have the same high-level programming interface that you are accustomed to today. However, state drivers have a built-in state cache that tracks the state of instrument settings at runtime. By knowing which state your instrument is in, you can minimize the number of steps it takes to reconfigure it to a new state. State drivers do this automatically, resulting in major run-time improvements over test programs written with traditional instrument drivers. In some cases, test execution time was sliced in half. 2. Simplify instrument driver development Although developing instrument drivers is not a difficult process, it can be very tedious and time-consuming, requiring a lot of resources. Instrument vendors who have recently begun delivering drivers with their instruments through the efforts of the VXIplug&play Systems Alliance are finding the investment to be more than they originally expected. End-users also find developing a complete, full-function driver for their instruments is too time-consuming, and will many times develop a driver implementing only those few functions required for their particular application. These partial drivers are not very useful for other users. LabWindows/CVI introduces an instrument driver wizard that automatically generates much of the code required for an instrument driver. 3. Improve instrument driver quality By automatically generating driver code with a wizard, developers will invariably find fewer bugs in their instrument drivers. More importantly, because the wizard generates code to follow a particular structure, instrument driver source code begins to look the same for all instruments, making it easier to support and maintain drivers in general. 4. Improve programming flexibility with drivers Because state drivers must keep track of all instrument states or settings, you now have access to all low-level instrument settings if needed (in addition to the high-level functions described earlier). The new state drivers not only keep track of the state of your instrument, but also manage your instrument settings in a number of different ways. For example, you can configure a state driver to operate in Test Development mode or Production mode. In test development mode, the driver automatically performs a number of checks to eliminate common programming errors when using a driver. For example, by enabling range-checking, your driver automatically checks each value that you send to your instrument to make sure it is in within a valid range before it is sent. By enabling coercion, the driver automatically coerces any values that you try to send to the instrument that are within range but invalid (e.g., you are trying to set the resolution on your DMM to 4 digits when it only understands 3½ or 4½. The driver automatically coerces your value to 4½). By enabling status-checking, the driver automatically checks the status of your instrument after each command you send to it to verify that no errors have occurred. Each of these modes is helpful when you are developing a test, to catch common instrument programming errors automatically. However, when you are finished with your test program and you want to deploy it on the production floor, you simply turn off these error-checking modes so that the driver executes at top speed. 5. Ready for advanced system development State drivers developed in LabWindows/CVI 5.0 are multithread safe, so you can use them in advanced, multithreaded parallel testing systems. In addition, state drivers developed with the Instrument Driver Development Wizard also perform simulation, so you can begin developing test programs with your instrument driver even if you do not have access to the instrument itself. 2

How State-Caching Drivers Work As a test program developer, you use a state driver exactly the same way that you would use traditional VXIplug&play drivers the high-level programming interface is identical. However, the inside of the instrument driver is very different. State drivers are built on an attribute model, meaning every high-level configuration function callable by end-users is actually broken down into a collection of low-level SetAttribute function calls inside the driver. Each SetAttribute call is funneled through a support library that manages the state of the instrument to determine if the attribute actually needs to be changed (or if the particular attribute is already configured on the instrument, the command is ignored). The architecture diagram below introduces the state driver structure. User Application LabWindows/CVI, LabVIEW, Visual Basic... High-level programming AOI (for ease of use) Instrument Driver Attribute Model (for performance) State Management Library (Engine) VISA State Cache Figure 1. How the State Management Engine Works The internal architecture of state drivers is split between the instrument driver code itself and the state management library, or engine, which manages the instrument settings and driver modes. For example, a high-level function for a function generator might have four parameters, or attributes, that it sets for generating a waveform waveform shape, frequency, amplitude, and DC offset. As you can imagine, this function is very easy to use. However, if you use this function in a common testing scenario to implement a frequency sweep, in which you continuously call this function to increment the frequency value of the waveform, you introduce tremendous overhead in your instrument. Each time you try to change the frequency, you must also reset the sinewave shape, amplitude, and offset even if they don t need to change. The state management engine is the key to eliminating this overhead. Here is how it works: GenerateWFM (shape=sine, freq=1000, amp=1.0, offset=0.0) is actually broken down in the driver source code into four separate attribute calls: SetAttribute (shape, sine) SetAttribute (freq, 1000) SetAttribute (amp, 1.0) SetAttribute (offset, 0.0) 3

Each time an attribute call is made, the following operations occur: 1. SetAttribute (freq, 1000) calls into the engine to set the frequency attribute to 1000. 2. If state-caching is ON, the engine checks to make sure the freq is not 100; if freq=1000, skip the command and continue to next. 3. If range-checking is ON, the engine checks to make sure 1000 is within range. 4. If log coercions is ON, the engine logs any coercions the driver makes to a log file. 5. If simulation is OFF, the engine sends the command to the instrument. 6. If status-checking is ON, the engine queries the instrument for its status to make sure no errors have occurred. The engine keeps track of the instrument states and the driver modes and then orchestrates the actual setting of the attribute accordingly. Because the state management engine handles the majority of the operations, the source code for the driver is very simple. The complexity of state caching is hidden both from the driver developer (because of the wizard) and from the driver user. A Word on State Integrity State-caching is a simple concept in theory, with many challenges when implemented in practice. Some test engineers are skeptical that an instrument driver can accurately track the state of every setting of a particular instrument at all times. The state-caching model in LabWindows/CVI 5.0 is a very flexible model with many different back doors and open entry points designed for handling peculiar instrument operations. It is important that test engineers understand the flexibility and practicality of the state-caching model implemented in LabWindows/CVI 5.0. Some of the common questions concerning state-caching are: Is it possible to track the values of every instrument setting at all times in software? IVI drivers do not attempt to track every value in software at all times. The cached values are built up in memory as your program runs. Each attribute stored in memory has a value that is either valid or invalid. When you initialize an IVI instrument driver, all attribute cache values are marked as invalid. Therefore, the first time your program accesses an attribute (sets it or gets it), the driver automatically communicates with the instrument directly and sets the initial value in the cache. These state-caching drivers have attribute tables that identify which attributes are dependent on other attributes. For example, when you change the range on a DMM, the resolution is also affected. In this case, the new value for range is stored in the cache, and the value for the resolution attribute is invalidated in the cache, because the software cannot be sure which new state the resolution attribute was set to. The next time your program accesses the resolution attribute, the IVI driver communicates with the instrument to get it or set it. By following this simple model of building up attribute values in software and maintaining an attribute dependency table, the states of instruments can be effectively tracked in memory. How does the IVI architecture handle range-checking of attribute values? Each driver contains range tables for each attribute. Range tables store valid values for each attribute. The engine uses range tables to verify that user-set values are within range for the instrument. There are three different types of range tables discrete, ranged, and coerced. Discrete tables are for attributes that have only discrete values as possible settings, such as the function attribute on a DMM. The function attribute can be set only to certain values volts DC, volts AC, amperes DC, and so on. Ranged attributes are attributes whose values must fall within upper and lower limits. Coerced attributes are attributes with values that fall within a specified range in specified values. For example, the horizontal timebase setting on an oscilloscope may fall between nanoseconds and seconds in 1x, 2x, and 5x increments. Coerced range tables automatically coerce any values to these appropriate values for the instrument before sending the values to the instrument. Even with this advanced level of range-checking, more flexibility is required to handle real instruments. For example, some attributes have dynamic range tables. Some attribute ranges depend on the mode in which the instrument is configured. The range of a DMM depends on the measurement function in which the DMM is configured. IVI drivers dynamically check these modes and direct the driver to use the appropriate range table, based on the settings of the instrument. In some cases, even this approach will not work. In these cases, the driver developer can simply call a function for dynamically computing the valid range of the attribute based on any number of settings. 4

How does the IVI architecture handle difficult attributes? Even with this simplified approach to state-caching, certain attributes on certain instruments can be problematic. To handle these cases, the IVI architecture provides a number of flexible options for the test programmer. One common example is attributes whose values are coerced by the instrument. Obviously, when instruments coerce the value of a setting after receiving a command from the user, it is very difficult for the software to actually match the values that are stored in the instrument. Coercion is handled in the following manner in IVI: 1. For instruments that coerce attribute values in a known method, IVI drivers contain complete range tables to track this coercion. For example, for oscilloscopes that accept horizontal timebase settings only in 1x, 2x, or 5x increments, the driver contains a range table structure that coerces the value to the appropriate 1x, 2x, or 5x increment before sending it to the instrument, as described above. However, for some attributes, coercion cannot be described in a simple range table structure. For these attributes, the driver developer can create a function to programmatically determine what the new value should be and coerce it before sending it to the instrument. In these cases, the coercion function may need to query the instrument to determine particular modes and attribute values, and use these values in the coercion algorithms. 2. For instruments that coerce attribute values consistently using an algorithm that cannot be determined (i.e., every time I 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 COERCED_BY_INSTRUMENT_ONLY. For example, imagine an instrument setting that is coerced by the instrument so that every time you send the instrument value X, the instrument coerces it to Y. Likewise, every time you send the value Y to the instrument, the instrument will accept it as Y. In this example, the state cache actually stores the source of the value that it is has recorded. For example, when you first send the value X to the instrument, the state cache stores X as a value set by the driver, while the instrument coerces X to Y internally. If you then try to get the value from the instrument, the driver will query the instrument and return Y (because it knows that Y is the actual value) and stores Y in the cache as the value that it got from the instrument. In the future, if you try to get the value from the instrument again, the driver will return Y without accessing the instrument. If you try to send X or Y to the instrument, the driver knows that the instrument is already set to this value and does not communicate with the instrument. 3. For instruments that coerce attribute values in a completely unknown method in which the dependency of attribute values cannot be determined, IVI allows you to disable caching for these particular attributes. If there is no way to accurately track the actual value of an attribute based on the value that the driver sends to the instrument, it is not practical to try to store values in software to match the instrument settings. For these examples, state-caching can simply be disabled. 4. 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 2, 3, and 4 above represent very difficult instrument programming examples. The IVI state-caching architecture handles these situations using the flexible options described. However, instruments that fall into these categories are not only hard to cache instrument values for, but also hard to program in general because of their inconsistent behavior. How does state-caching handle catastrophic events, such as someone turning off the VXI chassis? The IVI architecture does not have anything specifically designed to handle these types of events. Again, all driver functions return errors that can be checked, similar to standard programming practices. In addition, when catastrophic events occur, such as the chassis losing power, the current value of the state cache is only one of many problems that you will have to handle. What about ill-behaved instruments with unpredictable behavior? When writing a driver for an instrument that is poorly documented or ill-behaved, we recommend that many of the state-caching features simply be disabled in the driver to avoid problems. Of course, a structured architecture for controlling instruments, such as IVI, will quickly bring to light any instruments that have poorly documented or poorly implemented programming interfaces. These types of instruments are not only difficult to write a state-caching driver for, but also difficult to program in general. Hopefully, more rigid requirements on instrument drivers such as IVI will prompt instrument vendors to develop, implement, and document their instrument programming interfaces better. 5

Are state-caching drivers difficult to write? The automated development tools described in the next section make state-caching driver development possible. The wizard in LabWindows/CVI 5.0 automates much of the coding required, so the instrument driver developer can focus on the important aspects of the driver learning how the instrument and its attributes operate. Developing a State-Caching Driver with the Instrument Driver Development Wizard As you can see, state-caching drivers add a number of improvements in terms of test execution speed and test development tools. The next obvious question is How do I develop a state-caching driver? LabWindows/CVI 5.0 introduces a new instrument driver development wizard that automates the process of writing a state-caching instrument driver. The driver wizard operates in two steps the first step generates the basic structure of the instrument driver files (the source file, the header files, and the function panel files) and the second step is a browser/code generator that inserts functions into the source file based on the instrument attributes (i.e., setting, getting, and checking attribute values). The initial steps of the wizard prompt the user for values in a series of dialog boxes to generate the driver files. For example, the wizard asks you which type of instrument driver you are writing (scope, DMM, function generator, etc.), and provides a suggested template of functions as a starting point to help you architect the driver API. Some of the dialogs from the startup wizard are shown below. 6

7

Once you have gone through the initial wizard dialogs, the attribute browser presents all of the instrument attributes and each function associated with the attributes. From the browser window, you can easily navigate through the driver source code. Simply right-click to generate function code for a particular attribute callback function, or view the source code of an existing attribute callback function. The browser makes it very easy to visualize the structure of your instrument driver and quickly navigate to code segments. 8

Conclusion State drivers address many of the long-standing drawbacks and limitations of VXIplug&play drivers. However, this new approach to developing and implementing instrument drivers introduces very little change in how test developers actually use instrument drivers. With automated development tools such as the Instrument Driver Development Wizard in LabWindows/CVI 5.0, more advanced, better-performing, higher-quality instrument drivers will be developed much faster than is currently possible today. 9