In an earlier post, I described different flavors of instrument drivers. One kind of driver is called "IVI". These drivers actually come in two different forms: IVI-C and IVI-COM. In this article, I'll try to explain how each is used in LabVIEW, and how they are very different kinds of drivers.
Neither IVI-C nor IVI-COM drivers are written in native LabVIEW code. All of the IVI drivers that National Instruments makes are written in C (hence the name "IVI-C"). Their design was primarily intended for C developers, such as those using LabWindows/CVI. The IVI drivers that NI creates do come with source code--but you have to have at least some C programming skills to modify and recompile the source.
To use IVI-C drivers in LabVIEW, we provide wrapper VIs. If the C source code has a "DMM_ConfigureMeasurement" function, we create a wrapper VI called "DMM Configure Measurement" that knows how to call the C entry point. So even though the source code is C, the experience is pretty much the same as a native LabVIEW source code driver.
As an example, here's what the diagram looks like using a native LabVIEW DMM driver...
(Click to enlarge)
And here's a similar diagram using an IVI-C driver with a LabVIEW wrapper around it...
(Click to enlarge)
As you can see, the LabVIEW driver and IVI-C driver are nearly identical when used on the diagram.
Now let's compare this with an IVI-COM driver. The structure is similar, so at first glance, it would seem that IVI-C and IVI-COM drivers are equivalent.
If you dig a little deeper, you'll see that there are some issues. I want to highlight a couple of things...
- Usability of the driver types when creating your application
- Differences between the IVI-C class and specific interfaces, and the IVI-COM class and specific interfaces
The latter topic is worthy of its own post, so I'll briefly focus on a few of the usability concerns.
Default parameters
One very simple usability item is that subVIs can have required, recommended, and optional inputs, and they can have default values if you leave them unwired. IVI-COM drivers, on the other hand, have only required and optional arguments, and most are required. In the picture above, note that Initialize and Read both had parameters that I was required to wire in the IVI-COM case, but could ignore in the subVI case. It's a small thing, but it adds more objects and clutter to the diagram instead of letting me focus on the important stuff.
Instrument drivers in the palettes...
Here are a couple of the palette menus showing part of a VI-based driver...
It's easy to see the available functions. The help menu shows you the parameters as you hover over each item in the menu.
With IVI-COM drivers, though, you start with the generic ActiveX functions...
You have to drop an "Automation Open", find the right class in a very long list of all the ActiveX objects installed on your computer...
then drop Invoke and Property nodes to explore the class. And I do mean "explore". I had to hunt just to find the "Read" method. I thought it would be a top-level method of the top-level object, but you have to get to the "Measurement" sub-object and use its "Read" method.
LabVIEW 8 introduced the LabVIEW "Class Browser", making it easier to navigate deep object hierarchies. This is how I found the "Read" function, which has got to be one of the most important functions in the driver, buried deeply...
Let me summarize this post with something we've been saying for a long time. There's no one-size-fits-all driver that is perfect in every development environment. IVI-COM drivers are easiest to use in Visual Basic 6. LabVIEW Plug and Play drivers are easiest to use in LabVIEW. VXIpnp and IVI-C drivers are easiest to use in C environments. That may sound like common sense, but a lot of instrument vendors are having a hard time with this because they don't want to spend the time and effort (read "money") to support multiple environments.
Fortunately, some vendors are coming around to the idea.
Next time, I'll talk about one of my biggest technical issues with IVI-COM drivers. It all boils down to a specification document that says "should" instead of "shall".
I encourage you to post your own comments about the different kinds of driver technologies.
9 comments:
This might be a bit off topic, but I was wondering if VISA based instruments will every be able to be write to a type of Global Channel that would be configurable in MAX. The idea I am interested in is some way of merging VISA data points with other other global channels in a single task that could be used by labview or vi logger to aggregate analog inputs across DAQmx channels and VISA instruments.
That's an interesting question. NI-DAQmx, our data acquisition driver, is more channel-oriented. Our instrument drivers tend to be device-oriented. Part of this is limited by the devices and how they're internally put together. Part of it is, for lack of a better word, "tradition".
This is probably worthy of a future blog topic. Thanks for commenting.
great explanation on IVI-COM and IVI-C
Am I missing something? Why can't you put wrapper VIs around the IVI-COM functions in the same fashion that you do for IVI-C?
Good question. Theoretically, the answer is yes. I'd have to double-check, but I think the class IVI-COM interfaces are very similar to the class IVI-C interfaces, so you could build wrappers for those. You would be passing an ActiveX reference around the diagram instead of an IVI reference (so you wouldn't be able to see the IVI logical name).
In practice, I've found that the specific drivers rely heavily on properties. So I think you'd have wrappers around the handful of methods, and still use property nodes for much of the API. Whether a wrapper makes this easier is something that needs to be decided on a driver-by-driver basis, probably by whoever is creating the wrapper.
In IVI-C, the specific drivers are pretty uniform. Our LabVIEW Instrument Driver Import Wizard can automate the creation of wrappers.
I don't think we'd discourage someone from creating a wrapper, but it's probably a manual process since every specific IVI-COM interface is unique. You can't leverage the uniformity of the APIs the way we can in IVI-C.
Actually, your response just gave me another thought. Theoretically, you shouldn't have to develop a wrapper for each driver specifically -- different instances of a class (i.e. Tek scope vs. Agilent scope) should have the same methods and properties, so one wrapper VI could actually be applied to multiple drivers. That would be an advantage to IVI-COM. It sounds like this is not true in practice, however, so you would probably have to derive one wrapper from the other (probably only requiring the programmer to change the method/property name in the ActiveX node).
I think you understand the theory correctly. All class interfaces on IVI-COM drivers of the same instrument class are identical, so you would only need to develop the class wrapper once.
There are a couple of problems putting this into practice, though.
First, there's no guarantee that I can mix and match class and specific driver calls. I can't necessarily QueryInterface to get to a different interface and expect it to work. This may work with some drivers, but you'll have to ask the vendor if there are any special rules to follow. (E.g., you may have to call Initialize with class, specific, or both interfaces.)
Second, only the specific interface is going to (typically) provide all of the instrument functionality. So for many applications, you'll have to call something in the specific interface. With IVI-C, you can mix and match the calls. With IVI-COM, as I pointed out above, you're on your own.
Hi,
I want create IVI-C driver for switch. But I don't have any procedure or sample source of IVI-C driver. So could you tell me the any link that has the procedure for IVI-C driver and it's sample source.
Hi, Ganesh. Have you looked at the Instrument Driver Development Wizard that's part of LabWindows/CVI?
This is probably the best tool available for writing IVI-C drivers.
Post a Comment