Dictionary
| DLL | Dynamic Link Library |
| ADE | Application Development Environment |
| COM | Component Object Model |
Quick-Start Guide
- Download and install the “IVI Shared Components” from ivifoundation.org.
- Look for your instruments driver in the IVI Foundation driver registry.
- If the driver is a .NET type, download and install the “IVI.NET Shared Components” also from the same page.
- Install the IVI driver. (All IVI drivers will be installed to C:\Program Files (x86)\IVI Foundation\IVI\Drivers).
Shared Components
These components provide services to drivers and driver clients that need to be common to all drivers. This includes:
- Configuration Store (more further down this page)
You must install the IVI Shared Components before an IVIdriver can be installed.
- Go to the IVI Foundation Web site at http://www.ivifoundation.org.
- Locate Shared Components.
- Choose the IVIShared Components msi file for the Microsoft Windows Installer package or the IVI Shared Components .exe for the executable installer.
Driver Type (COM, C, NET, Class)
IVI-COM vs. ICI-C
There are two major driver types, -COM and -C. There are others as well like .NET APIs and class drivers or wrappers for certain programming environments, but these will be covered later. IVI-COM drivers are optimized for environments that support the Component Object Model (COM) such as Microsoft’s .NET programming environment which is programmed with C#/VB. IVI-C drivers are optimized for use in ANSI C development environments. COM drivers are superior in almost every way. Note that ideally, manufacturers would provide both types, to target the broadest range of ADEs, but most only provide IVI-C drivers. The table below compares the functionality of both driver flavours.
| IVI-COM | IVI-C | |
|---|---|---|
| .NET Support | • No manual coding is required to support .NET applications. • Interchangeable .NET applications can easily be developed. | • Special .NET attributes and method declarations are required in client applications. • Interchangeable .NET applications are not possible. |
| Interchangeability | • Interchangeable applications require no 3rd party components. • A single driver can easily support more than one IVI instrument class. • Applications can easily access different IVI-defined class interfaces. • Applications can mix calls to IVI-defined functions and instrument-specific functions easily and clearly. Errors are reported at compile time. | • Interchangeability requires proprietary class drivers, currently only available from a single supplier. • A single driver can only support a single IVI instrument class. • Mixing calls to IVI-defined functions and instrument-specific functions is error-prone, and many common errors cannot be detected until runtime. |
| Deployment | • Drivers are fully self-describing – only a single file needs to be imported by client applications. • Client applications do not require knowledge of where the driver is installed. | • Drivers require a header file, a driver DLL, a library file, a .fp file, and a .sub file. • Application code must explicitly specify the location of DLL, header, and library files. |
| Function Hierarchy | • Functions are located next to their associated attributes. • Function and attribute names are inherently scoped by their parent interface, allowing designers complete freedom in choosing meaningful names. | • Functions and attributes are located in two completely different hierarchies. • All function and attribute names must be globally unique, often leading to confusing name collisions between instrument-specific and class-compliant names. |
| Attribute Access | • Drivers provide simple and familiar “dot” syntax for accessing attributes. • The compiler reports many types of common programming errors. • Users enjoy a rich IntelliSense experience. • Very little typing is required for clients to access an attribute. | • Attribute access rely upon special attribute accessor functions. • Many common errors cannot be detected until runtime. • IntelliSense is only marginally useful. • Even simple attribute access operations require a significant amount of typing. |
| Repeated Capabilities | • Familiar collection interfaces clearly indicate what functionality applies to repeated capabilities. • Nested repeated capability access is intuitive. | • Users have no indication as to which attributes apply to a repeated capability and which apply to the driver as a whole. • Accessing nested repeated capabilities requires a special IVI-defined string-based syntax. • User must take care to pass the same repeated capability name to each function and attribute call. |
| Error Handling | • Driver error objects contain rich error information that is automatically reported in almost all popular ADEs. • Errors in the driver automatically generate exceptions that cannot be ignored by the client. | • Errors are reported as function return codes, which can easily be ignored by the application. • Application code must make explicit error checks after each driver call and then make a separate call into the driver to retrieve the error string. |
| Data Types | • Arrays and strings are fully self-describing and require no additional parameters to carry size information. • Memory is always allocated by the driver, so the client need not know ahead of time how much data will be returned. • Related items can be returned as a single object. | • Input arrays require an extra size parameter to be passed to the driver. • Output arrays require an extra buffer size parameter to be passed to the driver and an actual size parameter to be returned from the driver. • Output strings require an extra string length parameter to be returned from the driver. • Memory is always allocated by the client, so the application must know ahead of time how much data might be returned from the driver. • Struct parameters are not allowed or supported, so related items must always appear as separate parameters. |
| Remote Access | • Accessing a driver across a process or network requires no additional development work for the driver developer or the application programmer. | • No standard mechanism for cross-process or cross-machine access exists. Driver writers and application developers must resort to direct use of low-level Windows APIs. |
Instrument Interchangeability
Class Drivers
Interchangeability with IVI-C relies upon a special kind of driver known as a class driver. These class drivers expose generic function entry points that delegate to a specific driver written for a particular instrument. Users that want to write an interchangeable application use only functions exposed by the class driver. Class drivers are proprietary products as opposed to shared components distributed and maintained by the IVI Foundation. In addition, a different class driver must be provided for each instrument class. National Instruments is the only company that provides IVI class drivers, so companies implicitly rely on a single supplier. (Source)
If an end user or instrument manufacturer wants to achieve interchangeability for an instrument not defined by IVI, they can author what IVI terms a custom instrument class. For instance, a company such as Nokia may wish to define a generic cell phone instrument class to standardize functionality common to all of its mobile devices. For this to work with IVI-C, Nokia would have to author an IVI-C class driver. This involves implementing all of the delegation logic described above, as well as special error handling and session management logic prescribed by the IVI-C specifications. (Source)
| Class | IVI Driver |
|---|---|
| Digital multimeter (DMM) | IviDmm |
| Oscilloscope | IviScope |
| Arbitrary waveform/function generator | IviFgen |
| DC power supply | IviDCPwr |
| AC power supply | IviACPwr |
| Switch | IviSwtch |
| Power meter | IviPwrMeter |
| Spectrum analyzer | IviSpecAn |
| RF signal generator | IviRFSigGen |
| Upconverter | IviUpconverter |
| Downconverter | IviDownconverter |
| Digitizer | IviDigitizer |
| Counter/timer | IviCounter |
| Custom | Custom |
Interchangeability with IVI-com
By contrast, IVI-COM drivers require no special proprietary components to build interchangeable applications. The code for implementing IVI-defined functions is housed in the same DLL as the code for implementing instrument-specific functions. The IviSessionFactory component is provided by the IVI Foundation and automatically installed as part of the IVI Shared Components, with it an interchangeable driver can simply be created.
Configuration Store
This file stores the Driver Configuration to enable interchangeability without recompiling the source code. This is done by mapping a driver session and a hardware device to a logical name which then is used in code.
Manually edit the file the XML with a text editor or use a third-party editor like NI-MAX (free) or Matlab Test & Measurement Toolbox to make sure the format of the file won’t be corrupted. National Instruments provides an article on how to edit the configuration store with NI-MAX here. The IVI Foundation also provides resources like this video here for Matlab.