The Interchangeable Virtual Instrument Foundation was formed with the purpose of creating a standard that would allow engineers to use test equipment from different manufacturers without having to change their instrument control software. While this is an admirable goal, there's a little more to the story than this first blush would suggest. In particular, there are several different flavors of IVI, and which of these versions an engineer uses has implications for that engineer's flexibility. For instance, IVI-C drivers meet the goal of hardware independence - allowing users to swap instruments without rewriting software - but are supported only within a particular vendor\u2019s environment, whereas IVI-COM drivers are not restricted to one framework. This article will educate the T&M user on the different types of IVI drivers and examine tradeoffs in order to enable that engineer to make informed choices in test development.
It has been more than three years now since the IVI Foundation set out to create a set of instrument driver software standards that would allow T&M engineers to author test applications that were independent of the underlying test equipment. Initially, the standardization effort focused on defining C-language interfaces. The vision for these C-language drivers is that driver developers write conventional DLLs (on the Windows platform) that expose a flat hierarchy of instrument-specific functions. A separate component, termed a class driver, is then used to expose generic functions for interchangeability. Much of the initial momentum for C-style driver interfaces came from early work National Instruments had performed on C drivers with their LabWindows/CVI development environment. However, not long after the IVI Foundation\u2019s public inception, a number of active member companies began clamoring for a driver standard that would leverage Microsoft\u2019s ubiquitous component technology known as the Component Object Model (COM). After all, many of the goals Microsoft pursued with COM seemed enticingly similar to those sought by IVI.
T&M developers want flexibility in their choice of integrated development environment (IDE) as well as drivers that are easy to use in their IDE of choice, drivers that perform in multithreaded environments, and drivers that enable multi-process and multi-host applications. For their part, instrument vendors need a true component standard \u2013 one that allows them to develop a single driver for any IDE using standard Microsoft tools that leverage existing expertise, rather than proprietary tools with specific requirements and vendor-specific peculiarities. These motivations have culminated in a full suite of IVI standards for both C and COM, termed IVI-C and IVI-COM, respectively.
between these two distinct flavors of IVI is critical to a T&M engineer designing new test applications. While both flavors of IVI simplify interchangeability, it is more important to examine the specific technology in use, as this will dictate many of the benefits of IVI, such as the productivity gains T&M engineers experience.
Along with the COM standardization effort, the IVI Foundation has labored vigorously to develop architectural standards for IVI drivers. These standards place certain minimum requirements on IVI drivers independent of the specific instrument class the driver supports. The idea behind these architectural standards is that drivers must do certain fundamental operations in a standard way if interchangeability can be achieved in real-world applications. For instance, the architectural standards dictate how drivers are installed and configured. Additionally, the IVI Foundation will be developing, shipping, and maintaining specific software components for performing configuration, event handling, and other common tasks in a standard way. Though these architectural standards promise to enable interchangeability, their greater benefit lies in the ease-of-use, productivity features, and familiarity they bring to developing test applications with IVI drivers.
Again, the driver technology chosen, IVI-C or IVI-COM, is paramount in maximizing the benefits derived from this architectural standardization effort. Indeed, many vendors and users alike find more potential in the architectural standards combined with standardized component technology, such as COM, than they find in the potential of robust interchangeability itself. Nevertheless, the end result of the multi-pronged IVI standardization effort is an entire suite of standards, the many permutations of which are a persistent source of confusion for T&M users.
The first decision a T&M user will face when considering IVI drivers for an application is whether to use IVI-C or IVI-COM. Both interface technologies offer approximately the same level of interchangeability with regard to the underlying test equipment. That is to say, both technologies allow a user to write software that will not need to be recompiled when new test equipment is introduced into the system. This is what is meant by hardware independence. However, IVI-C and IVI-COM provide very different degrees of software independence.
IVI-COM drivers rely upon COM technology for operating seamlessly in various IDEs. Users working in Visual Basic, Visual C+ + , Delphi, LabVIEW, and many other environments, all enjoy a host of features for using IVI-COM drivers in their application. Object browsers provide a convenient, standardized way of viewing the functionality exposed by IVI-COM drivers. Microsoft\u2019s IntelliSense feature provides auto-completion capabilities that even the most experienced developers find indispensable in their day-to-day programming work. The most popular environments, Visual Basic and Visual C+ + , provide direct support for importing IVI-COM drivers in an application. In the case of Visual Basic, users simply select the \u201c Add Reference\u201d menu item, while Visual C+ + users have the#import compiler directive which makes using COM components in C+ + as easy as using them in VB \u2013l i t e r a l l y!! By comparison, IVI-C drivers really only have special support in a single environment \u2013 National Instruments\u2019 LabWindows/ CVI.
For instance, in IVI-C technology, instrument-specific drivers are developed that expose instrument-specific interfaces. Each function call exposed by the driver DLL is prefixed with the name of the instrument, so obviously, these functions cannot be called directly in an application that wants to have
interchangeable drivers. Rather, IVI-C drivers require the cooperation of a separate component known as a class driver. The class driver DLL exposes generic functions that delegate to the instrument-specific driver. In this way, IVI-C achieves syntactic hardware interchangeability.
At present, class drivers are only available from National Instruments and no other vendor or end-user has expressed interest in developing class drivers. IVI-COM drivers, on the other hand, do not need class drivers at all. COM inherently supports this type of polymorphic behavior, that is, the ability for code to determine at runtime the appropriate function to call. The notion of commercializing polymorphism in the form of class drivers seems anachronistic to this author.
The IVI Engine is a separate DLL that communicates with drivers at runtime to provide such services as range checking, state caching, and coercion. This means that IVI-C drivers cannot operate \u201cstand- alone\u201d, unlike their IVI-COM counterparts, which provide the same capabilities within the driver itself. Additionally, the presence of a single centralized component shared by all IVI-C drivers in an application creates performance considerations. Since the IVI Engine must service multiple IVI-C drivers, it is possible that these drivers could contend for some resources or services provided by IVI Engine.
Along with the consideration of C and COM interface standards, IVI drivers are distinguished by their differing levels of compliance. This point has been a source of confusion since IVI\u2019s inception. Essentially, there are two levels of compliance with an IVI driver \u2013 class-compliant drivers and custom drivers. The characteristics of the class-compliant drivers are somewhat self-explanatory. A class-compliant driver exposes one (or more) of the IVI-defined instrument class interfaces, such as DMM, oscilloscope, or function generator. The class-compliant driver must follow the exact syntax and semantics of the functions defined in the relevant IVI Foundation class specification. This is true regardless of whether the driver\u2019s interface technology is C or COM. Class-compliant drivers are the ones that offer the possibility of hardware independence, as other drivers in the same instrument class (e.g. other DMMs or other oscilloscopes) can be exchanged without having to recompile the application program. Many people are currently under the misapprehension that this is the only type of IVI driver, since the IVI moniker has become synonymous with interchangeability.However, it is perfectly legitimate to develop an IVI-compliant
classes are termed IVI custom drivers. These drivers usually represent instruments that are either too complex or too specialized for the IVI Foundation to standardize upon. However, the term \u201ccustom\u201d driver can be misleading, because it is not a \u201cfree-for-all\u201d with IVI custom drivers. Though these drivers do not comply with any class specification, they must comply with all of the architectural standards. This enables these drivers to take advantage of the various IVI infrastructure components that provide valuable services, such as configuration, installation, and event handling. Moreover, compliance with the architectural standards means that IVI custom drivers can be integrated with other IVI drivers in user applications. While this does not provide interchangeability between drivers, it does provide for
This action might not be possible to undo. Are you sure you want to continue?