IVI-C and IVI-COM, Part 2

In my last post, I compared IVI-C and IVI-COM drivers, but left one issue hanging. From a usability point of view, it's perhaps my biggest concern with IVI-COM.

In one of the IVI specifications, there's a sentence that reads...

When an IVI class-compliant specific driver implements instrument specific capabilities, the driver should export those capabilities in a way that is consistent with the class-defined capabilities.

This is a good thing. It means that when a user learns one IVI driver, they will have learned something about all IVI drivers that belong to the same class. It means that drivers are consistent with terminology, units of measure, and API structure.

If only it were true...

The quote above uses the word "should", which in software requirements parlance means, "it would be nice, but you can really do whatever you want". As you might expect, some vendors choose to do their own thing.

Well, the quote is actually half true. Because of the way that interchangeability of drivers works with IVI-C, specific drivers pretty much have to match the class drivers. But IVI-COM drivers can publish two different, disjoint interfaces--one for the class and one for the specific interface. So my beef is limited to IVI-COM drivers.

Let me give you an example. Looking at an IVI-COM driver from a major oscilloscope manufacturer, it has a class-compliant interface call IIviScope, and a specific-driver interface called ITekScope. If I want to set up "TV Triggering" on the scope, I can use the IIviScopeTriggerTv.Configure() method and pass in a polarity...

IVI Scope Class Interface:

Member Name	Description
IviScopeTVTriggerPolarityPositive	Configures the oscilloscope to trigger on a positive video sync pulse.
IviScopeTVTriggerPolarityNegative	Configures the oscilloscope to trigger on a negative video sync pulse.

Compare this with the ITekScopeTriggerVideo.Configure() method. (Even the interface name uses different terminology--"Video" vs. "TV".). This method also takes a polarity...

Specific Driver Interface:

Member Name	Description
TekScopeTriggerVideoPolarityInverted	Inverted. Sets the oscilloscope to trigger on a positive video sync pulse.
TekScopeTriggerVideoPolarityNormal	Normal. Sets the oscilloscope to trigger on a negative video sync pulse.

So let me summarize... "Positive" means "Inverted", and "Negative" means "Normal". Got that?

That's just one example. There are many more. So why would a vendor do this? I think there are a few possibilities...

• The vendor thinks their API is better than what the IVI Foundation came up with.
• The vendor has an existing driver (e.g., a VXIpnp driver) that they want compatibility with. Given the choice of compatibility with IVI and compatibility with an existing driver, they went with the latter.

Further, ask an instrument vendor which IVI-COM interface you should use, and they'll lead you to their specific driver interface. It incorporates all the functionality of the instrument, while the class interface only supports things that all scopes support. And it keeps you in their proprietary world.

I think there's something to be said for consistency with an industry standard. That's why LabVIEW 8 ships with instrument driver templates patterned after the IVI classes, and why we added tools to make it easy to create your own drivers that start with those templates.

IVI-C demonstrates that vendors can add specialized functionality to a driver, while still keeping it consistent with other drivers. IVI-COM failed to do this.