Filter
Top Products
101
•
•
•
•
•
•
Chapter 11
• • • • • •
Advanced Topics
Now that you’ve seen how to create a short program to perform a measurement in
popular programming environments, we want to introduce a few advanced IVI
topics: architecture, requirements for interchangeability, Configuration Store, and
future developments. These should broaden your view of the capabilities of IVI
drivers.
IVI Architecture
Up to this point, we’ve focused on using either an IVI-COM or IVI-C driver from a
specific ADE. The schematic below illustrates the use model for IVI drivers that was
deployed in the previous chapters. This use model is the simplest method of using
an IVI driver but does not enable interchangeability. This section explains the
architecture, including the capabilities of the various driver types and their
contribution to interchangeability.
Driver API
To support popular programming languages and development environments, IVI
drivers provide either an IVI-COM or an IVI-C API. Driver developers may provide
both interfaces, as well as wrapper interfaces that improve usability in specific
development environments.
The IVI-COM driver uses a standard Component Object Model (COM) interface
that provides access to the functions defined in the class through a hierarchy of
methods and properties.
The IVI-C driver appears as a dynamic link library (DLL), such as Windows DLL,
composed of standard C functions. The C specifications also define components
such as error handling and driver session creation and management, which ensure
robustness and interoperability.
The easiest interface to use in a given Application Development Environment is
one that is native to the environment. So a C interface works best in C and a COM
interface in Visual Basic. Some ADEs support only one type of interface, however,
which makes the choice simple.