What All IVI Drivers Do -- Inherent Capabilities

As a means to offer better performance in customer test applications, IVI drivers often support a feature known as state caching. The principle of state caching is quite simple, although in practice it can be extraordinarily difficult to implement properly.

When a end user enables state caching for an IVI driver, the driver attempts to determine if new settings passed into the driver are different from the actual instrument state. In this way, I/O traffic between the driver and the instrument is reduced, as fewer I/O calls are performed.

In the simplest example of when state caching improves performance, consider what happens when a user passes identical values several times in a row for the frequency property on a function generator driver. Without state caching, each call into the driver would result in an I/O function call to the instrument, whereas a driver performing state caching would detect that subsequent calls to the frequency property were redundant and should not result in any communication with the instrument. Correspondingly, the driver can "remember" the last known value for instrument properties so that queries can be performed by retrieving data from computer memory, rather than by performing instrument I/O.

As with caching schemes in other types of software systems, IVI driver state caching is frought with potential pitfalls. The chief challenge in properly implementing state caching is maintaining cache coherency. Complex instruments often have complex couplings between instrument settings, making it difficult for the driver to track whether or not settings stored in the driver cache are valid. Consequently, many instrument vendors choose not to implement state caching in the driver.

For more information on state caching, see IVI-3.1: Driver Architecture Specification.

Range checking in IVI drivers simply refers to the ability for the driver to test whether or not input values passed to the driver are within an acceptable range. End users typically use range checking during debugging and, after validation is complete, disable it to maximize performance.

For more information on range checking, see IVI-3.1: Driver Architecture Specification.

Instruments often accept only a discrete set of values for certain properties. For example, a DMM might only accept values such as 10 V, 100 V, 300 V for the voltage range setting. These discrete value sets will necessarily be different for different vendor's instruments. A Keysight DMM may accept 10 V, 100 V, 300 V while a Fluke DMM accepts 20 V, 200 V, and 400 V. As a result, IVI class specifications are forced to define such real-valued properties as accepting a continuous range of values, even though the underlying instrument only accepts a discrete set of values.

Following along with the DMM voltage range example, if a user sends a value of 150 V for the voltage range, the instrument will internally coerce the value to one of the accepted values, such as 300 V. To maximize interchangeability, the IVI class specifications provide guidance on how IVI drivers should coerce user requested values for specific properties.

To aid end users in building interchangeable applications, IVI drivers may implement a feature called coercion recording. If a user enables coercion recording, the IVI driver retains a log of each user value that it coerces. Standard functions in the IVI inherent capabilities provide the user with access to the driver's coercion log.

For more information on coercion, see IVI-3.1: Driver Architecture Specification.

A program written using an IVI driver will not be interchangeable if the program relies upon default settings within the instrument. This is because different instruments will have different default values for many important settings. Repeatable results can only be obtained if all of the instrument settings on which an operation depends are in a user-specified state.

IVI drivers may implement a feature called interchangeability checking to ensure that driver attributes relevant to a particular operation are in a user-specified state whenever that operation is performed. The IVI instrument class specifications all include class-specific sections detailing which driver attributes need to be in a known state for particular operations. The driver can then track these attributes and report a warning if one or more are not set explicitly by the client program before an important operation is performed.

Standard functions in the IVI inherent capabilities provide the user with the ability to enable interchangeability checking in the driver and to retrieve any warnings that occur. Typically, this feature is only used during development and debug of an application and disabled during normal operation, so as not to adversely impact performance.

For more information on interchangeability checking, see IVI-3.1: Driver Architecture Specification.

IVI drivers are often constructed for complex instruments that are difficult to procure or that are in high demand at the end user facility. Consequently, it may be the case that end users need to be able to test their application programs without being physically connected to an instrument. IVI driver simulation is a feature that allows end users to use IVI drivers without a physical connection to the instrument.

When an end user enables simulation in an IVI driver, the driver performs no I/O communication whatsoever. IVI drivers are free in their choice of mechanisms for returning meaningful output values to the end user, but the intent is that the user program should be able to proceed normally when calling functions on the driver. This allows the end user to exercise their test application before the actual hardware is available.

For more information on simulation, see IVI-3.1: Driver Architecture Specification.