IVI-COM and IVI-C at a Glance

IVI drivers currently come in two basic types -- IVI-COM and IVI-C. Although the functionality offered by both types of driver is often very similar, the fundamental differences in interface technology results in a very different end-user experience. This topic discusses some of the important differences between IVI-COM and IVI-C drivers.

The table below presents a summary of some of the important differences between IVI-COM and IVI-C drivers. A brief explanation of each point is given later in this topic.

IVI-COM Basics

IVI-COM drivers use Microsoft's standard COM technology to expose the driver's methods and properties. COM is a proven standard for building reusable, cross-language components on Windows. IVI-COM methods and properties are organized into interfaces that together form a hierarchy of driver functionality. IVI-COM drivers use standardized COM data types that can be understood in a wide variety of ADEs (application development environments).

IVI-COM Type Libraries

IVI-COM drivers are packaged as DLLs, like conventional Windows components. However, unlike conventional Windows components, IVI-COM DLLs contain description information about the functionality of the driver. This information is called the type library and offers such details as the name and signature of all driver functions, version information, parameter input/output direction, and even help information. Since the type library information is baked into the DLL, IVI-COM drivers are fully self-describing. This makes them easier to use in building programs because the developer only has to reference a single DLL to import the driver into their development environment. This also allows IVI-COM drivers to be used seamlessly in .NET programming languages, as is discussed later in this topic.

IVI-C Basics

IVI-C drivers are provided as conventional Windows DLLs with entry points exposed for each function supported by the driver. In addition to the DLL, IVI-C drivers include a header file (.h) and an import library (.lib). You use an IVI-C driver by including the header file in your program source code and then linking to the .lib file. IVI-C drivers use VISA data types, such as ViInt32, ViReal64, and ViChar.

IVI-C Function Panel and Attribute Files

Since IVI-C drivers rely upon basic Windows DLL technology, there is no way to represent a hierarchy of driver functionality in the DLL itself. Instead, IVI-C drivers use two additional files to present the logical organization of driver functions and attributes. The function panel file (.fp) is a variable-record binary file that presents the function hierarchy only. The attribute hierarchy is managed in a separate file called the attribute information file (.sub). The .sub file is a text file. The function and attribute hierarchies are managed separately because IVI-C development was heavily influenced by VXI Plug-n-Play driver standards, which had already established this bifurcation.

ADE Support for IVI-COM and IVI-C Drivers

Arguably the most important consideration in comparing IVI-COM and IVI-C drivers is the end user experience in various ADEs. Since IVI-COM drivers are based on Microsoft COM technology, it's not surprising that IVI-COM drivers offer the richest user experience in Microsoft ADEs. Users working in Visual C++, Visual C#, Visual Basic.NET and Visual Basic 6 will enjoy a host of features, such as object browsers, IntelliSense, and context-sensitive help.

IVI-COM drivers are also well-supported in environments targeting the test and measurement industry. Agilent® VEE® and MATLAB® provide built-in support for IVI-COM drivers, as does National Instruments® LabVIEW®. As of LabVIEW 8.0, a new feature called the Class Browser appeared, greatly simplifying the use of IVI-COM drivers in LabVIEW.

For more details on using an IVI-COM driver in various ADEs, see the topic Programming with the IVI-COM Driver in Various Development Environments.

The ADE story for IVI-C centers primarily around National Instruments LabWindows/CVI. IVI-C drivers work seamlessly in LabWindows/CVI, with built-in support for rendering the hierarchies and function panels stored in the .fp and .sub files. In all other environments, however, IVI-COM drivers provide a better user experience. LabWindows/CVI is a special case where IVI-COM drivers do not fare well. Users working in LabWindows/CVI will have a fundamental expectation that an IVI-C driver be provided for any instrument they need to use in that environment.

.NET Support and Interop Assemblies

Microsoft provides excellent .NET support for all COM components through .NET wrappers called interop assemblies. These interop assemblies are generated automatically with standard Microsoft tools (such as Visual Studio) and present a familiar .NET interface to a COM component. Since IVI-COM drivers are standard COM components, these interop assemblies can be produced for IVI-COM drivers in precisely the same way as for any other COM component. Programmers working in any .NET environement (C#, VB.NET, C++) can work with the IVI-COM driver as if it were a native .NET component.

The IVI Foundation provides a specification prescribing how this should be done, so that end users have a consistent experience with IVI-COM drivers in .NET. Please see IVI-3.14: Primary Interop Assembly Specification for details on building IVI-COM interop asemblies. More importantly, the IVI Foundation provides the interop assemblies required for achieving .NET interchangeability with IVI-COM drivers. These are installed as part of the IVI Shared Components.

In the "\IVI\Bin\Primary Interop Assemblies" subfolder of your IVI installation directory, you will find the interop assemblies for the IVI instrument classes as well as those for specific instrument drivers. The interop assemblies shipped by the IVI Foundation have names such as Ivi.Dmm.Interop.dll and Ivi.SpecAn.Interop.dll. Correspondingly, all instrument-specific interop assemblies must follow an IVI-specified convention:

<Company>.<Driver>.Interop.dll

Since IVI-C drivers are conventional Windows DLLs, there is no standard mechanism for creating .NET wrappers for IVI-C drivers. Instead, client programmers must add special declarations to their program for any IVI-C driver function they wish to use in their application. These declarations must be adorned with special .NET attributes that instruct the .NET environment on what kind of function is inside the driver. (For details on what's required to call DLL functions in .NET, see the MSDN documentation regarding the "DllImport" attribute and a featured called "P/Invoke".) The critical thing to note is that because there is no standard mechanism for creating .NET wrappers on conventional Windows DLLs, the IVI Foundation cannot supply a standard mechanism for programming against IVI-C drivers in .NET. Thus, interchangeability with IVI-C drivers in .NET is not possible.

Interchangeability

IVI-COM drivers and IVI-C drivers differ fundamentally is how they allow you to write interchangeable programs. With IVI-COM drivers, the developer references a standard, IVI Foundation-supplied DLL that defines the functions and attributes for a particular instrument class. These Foundation-supplied DLLs are referred to as the IVI-COM type libraries, and they are automatically installed as part of the IVI Shared Components. Another shared component called the COM Session Factory is used to instantiate an IVI-COM driver without having a hard-coded reference to the specific driver in use.

One important distinction between IVI-COM and IVI-C drivers when considering interchangeability is the number of instrument classes a single driver can support. Some instruments actually have functionality that spans more than one instrument class. For instance, some popular switch measure units offer both IviDmm and IviSwtch functionality, so supporting both sets of IVI-defined interfaces is very useful. With IVI-COM, a single driver such an instrument can be accommodated, as IVI-COM drivers can support any number of instrument classes at once. IVI-C drivers, however, have a fundamental limitation imposed by the attribute model they use. Each attribute in IVI-C is assigned a numeric identifier, but these identifiers are only unique within an instrument class -- not between instrument classes. Because of this, an IVI-C driver would not be able to support attributes from more than one instrument class, and so only a single class can be supported by any IVI-C driver.

Data Types

IVI-COM and IVI-C drivers use two different sets of data types. IVI-COM drivers use a special subset of the COM data type system, called automation data types. Simply put, this type system is designed to allow common access from a wide range of programming languages -- from Visual Basic 6 to C++ to C#. IVI-C drivers, on the other hand, use the VISA data type system, which is based on classic C data types.

The primitive data types, such as integers, floating point numbers, and booleans are represented similarly in both IVI-COM and IVI-C drivers. The key differences are in how arrays and strings are handled. IVI-COM drivers use the SAFEARRAY data type to represent arrays and the BSTR data type to represent strings. These data types are self describing in that the SAFEARRAY contains the number of elements in the array and the BSTR contains the length of the string. This means that when passing array parameters into or out of an IVI-COM driver, no extra parameters are required to describe the array. IVI-C drivers, on the other hand, need to pass extra "size" parameters to any IVI-C function that uses an array or string. (It is also a useful note that BSTR strings are allowed to contain embedded NULL characters, whereas IVI-C ViString parameters must always be NULL-terminated.)

In the IVI-COM example below, a client program is calling an IVI-COM driver function to fetch an array of measurements from the instrument. Note how only the array parameter need be returned from the function, as the size of the array is embedded in the SAFEARRAY data type.

In the IVI-C example below, a client program is calling an IVI-C driver function to read an from the instrument. In constrast to the previous IVI-COM example, the IVI-C programmer must pass in two extra parameters to describe the array -- one for the client to tell the driver the size of the input array, and one for the driver to tell the client how many array elements were returned.

Memory Allocation

IVI-COM and IVI-C drivers use opposite rules for memory allocation. This is important when dealing with string and array parameters. In IVI-COM, the driver typically allocates the memory associated with an output parameter, such as an array of measurement data. This is convenient for the end user because they do not need to know how much memory to allocate ahead of time. The driver simply allocates the memory required to return the output data. In some situations, such as when dealing with very large data sets, it may be desirable for the client program to pre-allocate memory and pass it to the driver. This allows memory to be reused across multiple calls to the driver. To support this use case, IVI-COM drivers allow pre-allocated memory to be passed in as well.

When using IVI-C drivers, the calling program must always allocate the memory for an output parameter. This requires the caller to know how much memory to allocate ahead of time and to pass in an extra parameter to the driver indicating the amount of memory that was allocated. This prevents the driver from writing too much data into the output parameter. The driver must then return an additional output parameter that indicates how much data was actually copied into the output buffer. It's up to the client program to determine whether or not all of the data has been retrieved.

Programming with Attributes

In both IVI-COM and IVI-C, drivers use functions and attributes to control the instrument. In both models, functions typically represent operations, such as taking a measurement, while attributes typically represent instrument settings, such as range or resolution. However, IVI-COM and IVI-C drivers have a very different model for programming attributes.

The IVI-COM model for programming attributes is straightforward. The functions and attributes are part of the same hierarchy. The user accesses an attribute using a simple assignment statement, as in the following:

Conventional Windows DLLs have no built-in notion of attributes, so IVI-C drivers rely upon a special idiom where dedicated "getter" and "setter" functions are used along with C macro identifiers. Every IVI-C driver supports the following standard set of attribute accessors, organized based on the data type of the attribute:

•GetAttributeViInt32, SetAttributeViInt32

•GetAttributeViInt64, SetAttributeViInt64

•GetAttributeViReal64, SetAttributeViReal64

•GetAttributeViString, SetAttributeViString

•GetAttributeViBoolean, SetAttributeViBoolean

•GetAttributeViSession, SetAttributeViSession

Each IVI-C attribute has an associated #define'd constant in the driver header file, and this constant is passed to the appropriate getter or setter function to read or write the attribute, as in the following example:

A couple of things are noteworthy about the IVI-C attribute model. First, the programmer must take care to use the correct type of attribute setter or getter for the attribute in question. In the above example, the IVISCOPE_ATTR_HORZ_SAMPLE_RATE attribute is a double-precision floating-point value, and the end user must know this when programming with the driver. There is no way for the compiler to catch any error, such as using SetAttributeViInt32 with a boolean type attribute.

The other thing to note about the IVI-C attribute model is that since the setter and getter function signatures are fixed for all attributes, there is no way to have parameterized attributes. In contrast, IVI-COM drivers support attributes with parameters.

Copyright 2013-16 Boonton. All rights reserved.