Happy end of 2006 to everybody out there.
In earlier posts, I've talked about the various kinds of instrument drivers. All of the modern types of instrument drivers work reasonably well in LabVIEW, but some work better than others. Specifically, LabVIEW Plug and Play instrument drivers (written in native LabVIEW source code) give LabVIEW users the best experience.
But not all instrument drivers are written in LabVIEW. This post talks about instrument drivers written in C, and how to bring them into the LabVIEW environment. C is considered a kind of "universal language"; C compilers are available for a huge number of platforms. So, vendors whose mission is to write a single driver that is usable on many platforms in many different environments often write a driver in C. (Though a reminder from an earlier post, the one-size-fits-all instrument driver isn't a particularly good idea.)
The first step in using a C-based driver in LabVIEW is to turn the C code into a DLL or Shared Library. Often, the person who wrote the driver does this for you, at least for Microsoft Windows. How to compile the driver is left as an exercise for the reader. My focus is on making the resulting shared library usable in LabVIEW.
To use a shared library (DLL) in LabVIEW, you use the Call Library Node (CLN) function on the diagram. You configure a CLN for every function you want to call. Typically, you create a single VI for each C function, and then use these VIs in higher-level diagrams. (Click to enlarge)
As you can imagine, if you have a shared library with dozens or hundreds of entry points, it can be tedious to make these VI wrappers. Fortunately, we have tools to make this easier.
Kinds of C-based Instrument Drivers
Broadly speaking, there are three different kinds of C-based instrument drivers...
- Drivers that do not conform to VXIpnp standards
- Drivers that conform only to VXIpnp standards
- Drivers that conform to both VXIpnp and IVI-C standards
The more standards a C-based driver conforms to, the more we know about how it is structured. The more we know about it, the better job we can do pulling the driver into the LabVIEW environment.
For drivers that don't conform to VXIpnp, we can't make any assumptions at all. We see this more often with somewhat esoteric instruments, or instruments from industries other than traditional test & measurement.
For VXIpnp drivers, we know they have an Initialize, a Close, a certain form of error checking, and a few other details. We don't know anything about instrument-specific functionality, such as whether a device is a DMM, a Scope, or something else.
IVI-C drivers go a step further, and define more of the API, at least for certain classes of instruments (such as DMMs, Scopes, Switches, etc.). This lets us more intelligently bring these drivers into the LabVIEW environment.
Tools for Importing
There are two separate LabVIEW tools you can use to help import these drivers. The first is the DLL Import Wizard, for importing generic (not VXIpnp or IVI-C) DLLs. The NI web site has a tutorial about this tool, so I won't go into much detail about it here.
If you have a VXIpnp or IVI-C driver, you want to use a different tool—the LabVIEW Instrument Driver Import Wizard, found on Instrument Driver Development Tools and Resources page on ni.com.
Unlike the generic DLL Import Wizard, the Instrument Driver Import Wizard is able to use its knowledge of the VXIpnp and IVI-C standards to create better wrapper VIs. It even makes an attempt to translate the C terminology in the help to LabVIEW terminology. Here's an example, showing the original C help and the translation into LabVIEW terminology...(Click to enlarge)
The Instrument Driver Import Wizard understands VISA and IVI refnum data types, it knows how the driver does error checking, and it creates better icons. It isn't perfect—there's a very good chance that you will want to tweak some of the resulting VIs to improve front panel layout, connector panes, and help. You may also want to clean up parameters to make them easier to use in LabVIEW—for example, integers that represent bitfields that you are supposed to "OR" together. But, the Instrument Driver Import Wizard handles a lot of the conversion for you.
If it isn't obvious... If you have a VXIpnp or IVI-C driver, you use the Import Instrument Driver Wizard, not the Generic DLL Import Wizard.
Final Caveats
The Instrument Driver Import Wizard used to be called the "CVI Function Panel Converter" and we shipped it with LabVIEW. Beginning with LabVIEW 8, we made it a web download. Some instrument vendors complained about this. They were claiming good LabVIEW support for their C-based drivers, but telling end users to go run the tool themselves to create the LabVIEW VIs.
My philosophy is that most end users don't need to run this tool. In an ideal world, the developer of the C instrument driver should be the one to run the LabVIEW Instrument Driver Import Wizard. Since the output of the tool often needs some tweaking (or even fixes to the C code), I'd prefer that only one person (the driver developer) create the wrapper. If every end user has to create the wrapper VIs, and then go hand-tweak them, it isn't very efficient. Many end users aren't going to understand the C driver well enough to make these changes easily.
Another caveat is that these tools only run on Windows. Fortunately, the resulting VIs can run on any LabVIEW platform (assuming you can recompile the DLL on the other platforms). Many VXIpnp drivers can run on multiple platforms. Interestingly, members of the IVI Foundation have told me that conformant IVI drivers can only run on Microsoft Windows. So even though we have instructions for porting IVI-C drivers to Linux, the Linux driver may not officially be an IVI driver. Regardless, the wrappers you create for LabVIEW should work with such a driver.
No comments:
Post a Comment