IVI Shared Component Installer

In order to facilitate IVI driver development and to ensure a consistent experience for end users building IVI-based test systems, the IVI Foundation develops and maintains a series of freely available software components. These components are collectively referred to as the IVI Shared Components, and they must be installed on any computer that will use IVI drivers. In fact, IVI driver installation programs are required to check for the presence of the IVI Shared Components before installing.

The following sections provide a brief overview of some of the most important IVI Shared Components.

The IVI Foundation provides an installer for the IVI Shared Components. Moreover, the Foundation's Shared Component installer is the only IVI-compliant way to install the IVI Shared Components. Third parties are not allowed to develop custom installation programs for the IVI Shared Components.

The IVI Shared Component installer creates a directory structure to house the IVI Shared Components as well as IVI drivers themselves. The root of this directory structure is referred to as the IVI install directory (<IviInstallDir>) and is typically <ProgramFilesDir>\IVI Foundation\IVI.

The IVI Shared Component installer is available for download from the IVI Foundation web site.

IVI Configuration Store

When the IVI Shared Components are installed, a special XML file named IviConfigurationStore.xml is placed in the <IviInstallDir>\Data directory. This file is known as the IVI Configuration Store and serves as a central repository for IVI driver configuration information.

IVI driver installers are required to populate the Configuration Store with information such as the instrument classes supported, the instrument models for which the driver is designed, and the physical channel names understood by the driver. End users add information to the Configuration Store to describe how they intend to use IVI drivers in their system. End users can specify logical names for IVI drivers and virtual names for channels.

For more information on the structure of the IVI Configuration Store, see IVI-3.5: Configuration Server Specification available on the IVI Foundation web site.

IVI Configuration Server

The IVI Foundation discourages users and driver developers from directly manipulating the Configuration Store XML file (IviConfigurationStore.xml). The Configuration Store is highly self-referential and easily corrupted if modified directly. Thus, the Foundation provides a COM component known as the IVI Configuration Server for programmatically reading and writing information to the Configuration Store.

The IVI Configuration Server is installed automatically by the IVI Shared Component installer. For more information on how to use the IVI Configuration Server, see IVI-3.5: Configuration Server Specification available on the IVI Foundation web site.

COM Session Factory

IVI-COM drivers, like all COM components, must be created using a specific, hard-coded reference to the main COM class. In Visual Basic, this reference takes the form of a class data type, while in Visual C++, a CLSID must be specified. Irrespective of the IDE in use, this identifier must somehow be provided to instantiate the driver and begin calling methods and properties. Yet, having a direct reference to such an instrument-specific item in an application program renders that application non-interchangeble. Specifically, if the user wishes to use a different instrument (and, hence, a different driver), then this CLSID (or class name in Visual Basic) must be manually changed and the program re-complied and re-linked.

The COM Session Factory (or, simply, the session factory)is a very simple COM component supplied with the IVI Shared Components. In spite of its simplicity, the session factory is a key to writing interchangeable applications that use IVI-COM drivers.

Rather than directly creating an IVI-COM driver using a CLSID (or the equivalent), the application program creates an instance of the session factory and then asks it to instantiate a specific IVI-COM driver. For this to work, the user must create a Logical Name in the IVI Configuration Store and associate that Logical Name with the specific IVI-COM driver they with to instantiate. The COM Session Factory simply looks up the Logical Name in the IVI Configuration Store, locates the associated IVI-COM driver and instantiates it accordingly.

Note that, as the name implies, the COM Session Factory is only relevant for IVI-COM drivers. IVI-C drivers use a completely different mechanims (namely, IVI Class Drivers), to facilitate interchangeability.

The COM Session Factory is installed automatically by the IVI Shared Component installer. For more information on how to use the IVI Session Factory, see IVI-3.6: COM Session Factory Specification available on the IVI Foundation web site.

IVI-COM Type Libraries

Part of the IVI Shared Components include a series of COM type libraries that contain the interface definitions for the IVI inherent capabilities as well as for all IVI instrument classes. These type libraries are installed in <IviInstallDir>\Bin and are generally named <IviClass>TypeLib.dll. For instance, the type library containing the interface definitions for the IviDmm instrument class is IviDmmTypeLib.dll.

Client applications must directly reference the IVI-COM type libraries from their projects in order to call methods and properties in IVI-defined interfaces. All client applications must include a reference to IviDriverTypeLib.dll, since this type library houses the interface definitions for the IVI inherent capabilities. Application programs must also reference the type library containing the interface definitions for any class-compliant interfaces they wish to support.

Copyright 2013-16 Boonton. All rights reserved.