Unintended Consequences Are Helping Us All

When the LXI standard was developed, the authors added a requirement that had been absent from all previous instrumentation standards. Specifically, they mandated that all LXI-compliant instruments must ship with an Interchangeable Virtual Instrument (IVI) driver. They gave this some teeth by requiring that all LXI-compliant instruments have an IVI driver to pass the certification process.

More than being able to tout LXI as the most interoperable standard, this was a smart engineering decision. The IVI standard provides for a driver that can be loaded easily into Windows environments to simplify instrument programming. Virtually any language then can be used to directly program the instrument for automated testing. The driver integrates nicely into most languages so features such as IntelliSense work just as they would for native language calls.

Work on what became the IVI standard preceded LXI by about six years, 1998 vs. 2004, and IVI-compliant instrument drivers were available long before the first LXI instrument was introduced. While many vendors were providing IVI drivers, there were multiple cases in which they would introduce an instrument long before they would provide the IVI driver.

This had two consequences: Users could not count on a standard driver being available, and vendors often were writing the driver as an afterthought. As a result, the quality and timeliness of the driver often fell short of customer expectations.

Now that LXI requires an IVI driver to ship with every compliant instrument, things appear to be changing for the better. First, vendors are integrating the IVI driver into their development process to ensure that it’s ready at introduction. Second, they now are realizing that having a quality driver is not a competitive advantage but rather a competitive necessity.

Some expect that instruments with other interfaces—PXI, USB, and AXIe—will increasingly include IVI drivers at first product shipment. This would be a win-win situation for both users and vendors.

In the past, engineers building an automated test system may have found it difficult to mix and match instruments from various vendors because the task of stitching together a program with different driver types was confusing. We now are approaching the time when this barrier is beginning to crumble.

When most new instruments ship with a standard driver type, one more barrier to building an automated test system goes away. The only caveat: It is unlikely that IVI drivers will be provided for most legacy instrumentation even though the majority of the existing code has been written for these instruments.

Like most industry standards, IVI is a mixed bag and is not the answer for every situation. For example, IVI drivers are designed for Windows environments and don’t do anything for the Linux community.

There also are two common types of IVI drivers: IVI-C and IVI-COM. This adds complexity to setup and programming. On the plus side, IVI incorporates the idea of a class driver.

A class driver provides a standard application programming interface (API) for a given type of instrument such as a DMM, oscilloscope, or spectrum analyzer. An engineer programming to the class driver receives a common set of measurement functions across many instrument types and across similar instruments from different vendors. This is a new, higher level of code portability and instrument interchangeability for the test industry.

It appears that an unintended consequence of requiring a standard instrument driver in the LXI standard may be that the entire industry receives the same standard. This isn’t yet a reality, but the industry seems to be heading that way. The biggest beneficiaries are likely to be the engineers who are creating new automated test systems.

FOR MORE INFORMATION

on the IVI Foundation
enter this rsleads URL
www.rsleads.com/106ee-203

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!