Using IVI-C and VXIpnp Drivers in LabVIEW

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.

Read more of this article...

LabVIEW API Design

Sorry it's been a while since my last post. I've been traveling, most recently to New Mexico and Colorado for National Instruments Technical Symposia, and a little bit of photography at the Bosque del Apache National Wildlife Refuge.

In my role at National Instruments, I work with many of the driver and toolkit groups that provide LabVIEW APIs for their products. We make decisions about how to best represent our products in easy to learn and easy to use ways.

We're often faced with difficult tradeoffs, and some decisions come down to a "gut feel" by those of us involved. I thought I'd share some of the thought process that goes into making a good API for LabVIEW.

First, a little history. Many of you have attended, or at least heard of, NIWeek—Thousands of users, dozens of presentations, dozens of exhibitors. Did you know that we have a similar NI-only event called "NITech"? This is where NI R&D sets aside three days to have NI engineers present to other other NI engineers. We learn about the latest hardware and software technologies, ongoing research ideas, and good development practices. (And just as at NIWeek, we have fun, too.)

At NITech 2001, I co-presented a session on "Why Good Hardware APIs are Different in LabVIEW, CVI, VB, and VC". Each development environment is different. Some differences are radical, such as LabVIEW's data flow approach vs. text languages that are control flow. Some are as simple as the differences in the online help systems, or the fact that LabVIEW APIs have icons in addition to function names. One conclusion of the presentation is that it's worth it to fine-tune an API for the development environment your users are going to use.

For NITech 2002, I expanded the presentation and called it "Good LabVIEW API Design". I moved it out into the open at NIWeek 2003, where I updated it and called it "Developing High Quality LabVIEW Add-ons". For NIWeek 2004, I updated it once again, and put some spin on the name—"Advanced LabVIEW Design—Usability, Reusability, and Maintainability".

Some of the ideas from those presentations have been incorporated into either the LabVIEW Development Guidelines (available in the LabVIEW help), or the Instrument Driver Development Guidelines. I don't plan to rehash every guideline here, but there are a few ideas from the presentations I'd like to cover from time to time.

At a recent LXI meeting, I was asked whether it made sense for IVI-COM drivers to have LabVIEW VI wrappers around them. That is, instead of having users use the IVI-COM drivers as COM objects directly in LabVIEW, should he create a VI for every property and method in the driver? As with so many things, the answer is, "it depends".

When someone asks, "should I do it this way?", you have to step back and consider the alternatives. There's not necesssarily one perfect way.

A few years ago, one of the well-known instrument vendors developed LabVIEW instrument drivers that consisted of hundreds of VIs. Basically, they had one VI per SCPI command. In a scope API, you called one VI to set coupling, and another to set vertical range, and another for vertical offset. In my book, this was pretty low-level tedious programming. It was also error-prone—some instruments, for example, have a particular order in which you need to send the commands.

I've argued that users really want a higher-level instrument driver—"configure channel" or "configure vertical", not the lower-level components. Let the author of the instrument driver figure out the programming details once, instead of pushing that onto each user. Still, some vendors really like the low-level approach, since it's so powerful and so granular. I think users who want such a low-level approach can use VISA Write to send their own SCPI commands.

Let me restate this to make the tradeoffs clearer. Approach 1 is to have hundreds of simple VIs that consist mostly of VISA Write calls. The driver covers every command the instrument can handle. Approach 2 is to have only a few more complex, higher-level VIs that are commonly used. If you want something more granular, you either modify one of the existing VIs, or you create your own new VI with a VISA Write in it.

I generally lean towards approach 2. The first approach is often overwhelming, and users don't know where to start and how to put the pieces together.

The IVI APIs presented some new challenges. They're more complex, and it's not as simple to insert a VISA Write in your code to tweak a specific setting. So the IVI-C APIs have a few high-level methods, and hundreds of low-level properties. When we designed the first IVI-C APIs for the various instrument classes, we tried to make it so that 80% of typical user applications could be accomplished with only the higher-level methods.

The palette menus for an IVI-C driver in LabVIEW expose the high-level functions. We often also include a single property node to make it easy to get to the rest of the API. Thus, the palettes lead you to the right starting place for the API.

The same idea could map to IVI-COM. Unfortunately, IVI-COM drivers do not always expose a high-level approach in the specific driver interface. Recall from my earlier post about IVI-C and IVI-COM, that the specific interface to an IVI-COM driver doesn't conform to any standard.

So, since I don't know anything about the structure of the API, I can't recommend creating LabVIEW wrappers around it. And because I know that most IVI-COM specific interfaces use a low-level, property-centric approach, I usually actively discourage creating wrapper VIs. The end user is going to have to explore the entire API to figure out how to put it together in an application. Fortunately, the LabVIEW Class Browser (under the View menu, and new in 8.0, I think), makes it somewhat easier to explore IVI-COM drivers.

On the other hand, if you have a well-designed API that has easy-to-use high-level functions, it makes sense to highlight those in the palette menus and lead users to them.

More on API design in future posts.

Read more of this article...

Emulating Legacy Instruments

This is a story of one of the projects we have in the lab. It's an experiment and proof of concept. At this point, we aren't committed to creating a product out of this idea. I'm interested in hearing comments you have about it. We presented a paper about it at AutoTestCon a couple of years ago, and I've demo'd the system to a few key customers.

We have customers who have aging test systems, often based on discontinued GPIB instrumentation. There's often no money to update the overall system. Changing out hardware usually implies modifying the software. The software has often gone through some sort of validation process, so any change to the software can become extremely expensive since it would have to be revalidated.

If an instrument fails, the engineers can either hope for vast amounts of money to rebuild the entire test system with modern hardware, or they can try to repair or replace the old equipment. eBay has become a useful tool for finding old instrumentation.

So our experiment was to take a modern PXI-based measurement system, and make it pretend to be a GPIB instrument. The PXI controller listens for commands on its built-in GPIB interface. We wrote software that parses those commands and maps them to specific LabVIEW VIs running on the controller. Responses are sent back out the GPIB interface.

I imposed a couple of requirements to make things interesting...

• The system had to be as generic as possible. I didn't want to encode any traits of a DMM or Scope or Spectrum Analyzer into the system. For this, we created an XML schema to define the commands that the system understands, as well as how those commands map to VI calls.


• The system had to be extensible by end users using LabVIEW. We aren't making turnkey instrument replacements; we're making a framework for end users. This lets end users (or system integrators) control the fidelity of their emulation. This might range from deriving custom measurements, to slowing down measurements to more accurately emulate legacy instrumentation.

We came up with an editor to map commands to VIs. With this editor, you don't have to edit the XML directly. Here's a screenshot showing the CURVe? command for a scope...

When the system is running, the display shows a log of all the commands and responses... (Click to enlarge.)

So where are we now? The system works. It's got some rough edges—mostly things that could be easier. As a proof of concept, our engineers did a wonderful job. It's pretty cool to watch this system in action. But, we're waiting for customers to tell us whether and how we should take the idea further.

The biggest piece of feedback so far is that customers wish it were more "turnkey". It's one thing to emulate the command set of an aging instrument. It's another to faithfully emulate measurements. Our PXI-4070 6 1/2 digit DMM is faster and more accurate than many older box-based 6 1/2 digit DMMs. But you usually would rather have equivalent accuracy, not more accuracy. A faster and more accurate measurement could be a problem in some test systems.

I also want to point out that more turnkey solutions are available. WinSoft (a National Instruments Alliance Partner and Agilent Channel Partner) has a product called WinSoft Instrument System Emulator (WISE). I do not have experience with their products, but I know they have years of real-world experience.

If you've got thoughts on our instrument emulation project, please let me know.

Read more of this article...

LAN Is Simple, Right?

I was in the Boston area last week at the latest LXI Consortium meeting. We spent some time the first day putting together our "lessons learned" from building a multi-vendor Ethernet-based test system. To no one's surprise, we had a couple of pages of feedback. One of the most prominent points was that the demo took three to four times the amount of effort we expected. I haven't crunched the exact numbers, but our one team-week turned into several, including some near all-night sessions. Our "team" consisted of experts from Agilent, Rohde & Schwarz, VXI Technologies, National Instruments, and others.

I'm sure those of you who build test systems for a living are laughing at us. You would have wisely planned for the extra effort, despite (or perhaps because of) the fact that we were using LAN instead of GPIB, PXI, or some other more traditional instrumentation bus.

And you'd be right to laugh at us. I think we were a little naïve.

Speaking of naïve, I had my own "IT issues" on my home network over the weekend. The parallels to an LXI system are striking...

I had a simple problem I wanted to solve: I needed more disk space.

As many of you know, one of my creative outlets is photography. Before the LXI meeting, I was in Vermont for a photo workshop with David Middleton and Rod Barbee. I brought home several gigabytes of digital images.

I've been making backups on DVDs, but they aren't very archival, and I need a lot of them to hold my images. I could have bought a simple internal or USB hard drive and been happy. But no! I had to go for a RAID network attached storage device.

In theory, this is a simple solution. The storage device is a simple device with a LAN interface. It automatically works out the network connection. There's a simple tool for discovering the device on the network, and it has a web server built in to let you configure various options. Sounds like LXI, doesn't it?

You've probably surmised by now that something went wrong. To make a long story shorter, it turns out that my new network storage device is incompatible with my network router. Both the network router and storage device are from respected companies, but somehow they started fighting over the network.

I "solved" the problem by buying a new wireless+100-Base-T $30 router. I looked at the gigabit ethernet routers, but they're about 5X the cost. Yikes!

The new router has a simple "getting started" utility, and you configure it through its web server. Sound familiar? It only took me a few tries to get it to work wired, but I'm still struggling with the wireless security.

Ethernet is just supposed to work! When I bought my storage device, I couldn't have conceived of all these hassles. I didn't budget for the extra time and equipment. Recall that I was a network administrator at an earlier point in my NI career, so I consider myself a little more savvy than most network users. Besides, I just helped build an expensive LXI test system! How hard can it be to add a storage device to my home network?

I'm up and hobbling right now, but I can't help thinking about how simple it would have been to plug in a simple USB device.

Read more of this article...

A Geek Hotel

Yeah, "Geek", not "Greek". I must be staying in the geekiest hotel on the planet.

I have no desire to take a Geek Cruise, and I scored unsurprisingly low on the Geek Test*, but I did willingly choose to stay at the Hotel@MIT. I was attracted to the hotel because of its location and promise of good internet connectivity.

I was expecting the modern decor of the lobby, and not entirely surprised by an exhibit of historical MIT robots in the lobby. I failed to expect the bedspreads...

Now don't get me wrong. This is a really nice hotel, close to the red line, and for those needing a deeper geek fix, the MIT Museum.

* As a team-building exercise (okay, it was really just a diversion from work), my part of the LabVIEW group took the geek test. The highest score was by a woman who got points for having designed a nuclear device in college.

Read more of this article...

The Spy Among Us -- Debugging I/O

Have you used NI Spy? It's one of our software tools for helping you see and understand the messages sent to instruments. It's especially useful for seeing the low-level SCPI commands sent to Serial, GPIB, or LAN instruments...

It's useful for debugging, optimizing, or just learning more about instrumentation.

NI Spy only works when using NI Software. For example, you'll only see VISA calls if you use NI-VISA, and you'll only see GPIB calls if you use NI-488.2. (Spy also works for NI's Modular Instrument drivers, NI-CAN, NI-DeviceNet, NI's IVI Class Drivers, and maybe some other drivers I'm forgetting.)

I want to be clear that Spy is not a hardware bus analyzer. We sell a GPIB Bus Analyzer for really low-level debugging, but most users can get by with NI Spy.

I find NI Spy especially useful when I run into problems with an instrument driver. If I have a LabVIEW source code driver, I can sometimes go into it and figure out what we're sending to the instrument. But the strings we send to instruments aren't usually constants; usually some part of the string is computed. If I want to know what we really sent to the instrument, NI Spy can show me. Obviously, if you don't have LabVIEW source code to look through, NI Spy may be your only choice.

For example, I have a C-based driver for talking to the Agilent 34401A DMM. It works fine with this DMM. My problems started when I used a different instrument that could pretend to be the Agilent 34401A. There was actually a bug in the C driver that caused it to send an invalid command. The real 34401A didn't care, but the emulation mode of this second instrument failed.

With NI Spy, I can see the actual SCPI command sent to the instrument...


Here I can see that we're sending ":CONF:VOLT AUTO,DEF". If I go look at the official 34401A command reference, I see that the syntax is supposed to be ":CONF:VOLT DEF,DEF". The "AUTO" is wrong.

I had the C source code to the driver, so I tried to find the mistake in the source. It wasn't entirely obvious. Searching for "VOLT" or "AUTO,DEF" doesn't work. Here's the snippet of code that's wrong...

        /*  Configure the measurement  */
        if (autorange == VI_ON)
            Fmt (wrtBuf, "%s<:CONF:%s AUTO,%s\r\n", funcStr[func], resolStr[resol]);  

Without NI Spy, it would have taken me even longer to solve the problem.

By the way, I reported the problem to both the provider of the C driver, as well as to the provider of the instrument emulator.

Finally, I want to highlight a few features we added in LabVIEW 8...

• NI Spy was ported to Linux and Mac. (It was originally written in MFC for Windows. The Spy team rewrote it in LabVIEW to port it to these other platforms.)
  
• The logged calls make more sense for LabVIEW users. Before LabVIEW 8, you only saw the NI-488.2 or NI-VISA C-language calls. Here's the log from a simple write followed by a read...
  
  While this gives you some insight into how LabVIEW calls NI-VISA under the hood, it's not always easy to map this to your block diagram. Note that I hid six hundred calls to viWaitOnEvent as we waited for the I/O to complete. So in LabVIEW 8, the output looks like this...
  
  This is from a slightly different driver, but you see the idea. The function names match your diagram, and you don't have to look at the C-language calls.
  
• In LabVIEW 8.2, we did the same sort of simplification for the GPIB functions in LabVIEW. You see functions such as "GPIB Read", not "ibrda".
  

There are a lot of other features of NI Spy that I won't go into here. You can track instrument calls from multiple threads and processes. You can see timestamps to help debug tricky timing situations. It's an indispensable tool for users and developers of instrument drivers.

Read more of this article...

Instrument Drivers and the LabVIEW Community

Sorry it's been a couple of weeks since my last posting. I've been on vacation in the Big Bend area of Texas. It's a beautiful part of the state, and here's a taste for those of you who've never been there...

This is an Agave Havardiana in the Chisos Basin in the central part of the park. (Image Copyright © 2006 Brian H. Powell. All Rights Reserved.)

This area is a long way from, well, anywhere. Not a lot of people live here on either side of the border. There are a few small towns, such as Terlingua and Marfa. These places have developed a strong sense of community. We went to the community theater in Terlingua on the opening night of a three-night run. Most of the town was there in the un-air-conditioned building, with a few dozen plastic lawn chairs for the audience. And we were most welcome. It didn't matter that we were only staying a few days; we were part of the community. People look after each other out here.

And that's why it's great to have a LabVIEW community. While it's good to know that you can contact NI and get technical support, we have the tremendous privilege of having a community of amazingly smart and experienced users around us. If you spend much time on the NI Discussion Forums, you know of helpful contributors such as Dennis Knutson, Christophe Altenbach, Albert Geven, and many others.

There are many other parts of the community...

• OpenG.org
  
• LabVIEW Advanced Virtual Architects
  
• The Info-LabVIEW Mailing List
  
• Advanced LabVIEW Architects of the Rocky Mountains
  
• DaqMan.com
  
• "OCLabVIEW" Orange County LabVIEW Community
  
• Romanian LabVIEW Users' Club
  
• ...
  

These groups foster the sharing of ideas, techniques, and code. Sorry if I left out your favorite site.

Like every community, these places are only useful as long as people participate. If nobody is willing to get on stage, it's not going to be much of a play.

There's one important part of the LabVIEW community I want to highlight, and I want to encourage you to contribute to it. It's the Instrument Driver Network (IDNet). Have you ever noticed the button that says, "Submit Drivers"? It's a way for people to share their instrument drivers back to the LabVIEW community.

We have instrument drivers for thousands of instruments on IDNet, but there's room for more. We write a lot of the drivers ourselves, but only if we can get an instrument in-house to work with. We don't have easy access to older instruments, or obscure or expensive instruments. When you can't find an instrument driver for your instrument on IDNet, you can always try posting a query on the Discussion Forums to see if someone else has done it. Failing that, you may end up having to write your own driver.

When that happens, I encourage you to submit your driver back to IDNet, so we can share it with the rest of the LabVIEW community. You could save somebody a lot of time.

And I encourage you to do this even if you've only written a few VIs and haven't done a full-fledged instrument driver. If you needed only a few functions, the next user may also need only those same functions. Regardless, it's easier for the next user to start from your code instead of starting from nothing.

When you submit your driver, we'll take a look at it before posting it. We'd obviously enjoy receiving a complete, tested driver that conforms to our guidelines, so that we can certify it, but we can post "un-certified" drivers, too. (More on certification in a future post.)

So next time you're writing some VIs to talk to an instrument, support your community and volunteer to go up on stage.

Read more of this article...

What is LXI?

A comment on an older post asked about LXI. What is LXI, and what does it mean for LabVIEW users?

LXI stands for LAN Extensions for Instrumentation. The name follows in the fine tradition of VXI (VME Extensions for Instrumentation) and PXI (PCI Extensions for Instrumentation). There's a standards body that defines the LXI standard, which specifies what an instrument has to satisfy in order to get an LXI logo on its front panel.

LXI defines three classes of conformance. Class C is the simplest—basically the instrument has to have an Ethernet port and be able to serve up a web page. (There are many more operational details in the spec, such as specifying how devices get an IP address.) Class B adds IEEE-1588 timing and synchronization (see below). Class A adds a Wired Trigger Bus, which provides more precise timing and synchronization than you can get over Ethernet. (Again, I'm simplifying to what most users need to know. There are many operational details required for true conformance. Read the specs.)

Many Class C devices are just repackaged versions of older GPIB designs, adding Ethernet as a new way to talk to your DMM or Oscilloscope. (Many devices include connectors for Ethernet, GPIB, and USB in one package. Ethernet gives you distance. USB gives you plug and play simplicity. And as one test engineer put it, "GPIB just works".

Class A and B devices add complexity (and cost) in order to get better timing and synchronization. Most of the LXI-compliant devices available now are class C.

To be clear, National Instruments is not a member of the LXI Consortium. But I do pay attention to it. I've read the standard. I've been to some of the meetings. I've programmed a test system of LXI devices. I have firsthand experience with LXI.

LXI — Yet Another Way To Build a Test System

One of the many marketing messages behind LXI is that it is the "successor to GPIB". I think a more realistic message is "yet another way to build a test system". LAN-based instrumentation systems have their pros and cons. There are some things that are better than GPIB. There are some things that are worse.

LabVIEW is the best way to build a test system, LXI included. (Maybe I'm a bit biased. ;-) As T&M World editor Rick Nelson said recently in his LXI blog, the reality is that a lot of test systems are going to contain a variety of bus technologies. The purpose of VISA was to make it easier to incorporate new bus technologies into existing test systems. Work was done in the mid-1990's to produce the VXI-11 standard for Ethernet-based instrumentation. LabVIEW and VISA have been supporting LAN-based devices for years.

When is LXI right for you?

The one clear advantage that Ethernet has over most other bus technologies is distance. You can distribute instrumentation across the globe and talk to those devices over the internet. However, the further you distribute nodes on Ethernet, the more you run into issues with security, reliability, and timing and synchronization.

The LXI Consortium realizes that timing and synchronization are hard to handle, since you have less control over how packets are propagated through the network. That's why LXI adopted the IEEE-1588 standard for precision timing over Ethernet.

With IEEE-1588, you can trigger across a network with an accuracy of less than a microsecond. This level of accuracy has some constraints. You can only get this accuracy if you're connected through a simple network hub. Most corporate networks (and many home networks) use a network switch or router. These devices slow packet transfer by a few microseconds. It's imperceptible when viewing web pages, but these delays could cause problems in a high-end RF test system. NI has a PCI-1588 Ethernet controller. We publish 1588 synchronization specs for different network configurations in our PCI-1588 data sheet.

So, while LAN-based instrumentation is great for distributing systems across the miles, IEEE-1588 synchronization works best in small closed networks. (Note: IEEE-1588 is currently being revised to have higher accuracy. It appears the new version will not be backwards compatible with the current version.)

LXI—Simpler Cabling?

Here's an example of why no one pays me to build test systems...

This shows the back of a test system built mostly out of LXI class A devices. Ethernet cables, Wired Trigger Bus cables, RF signal cables, power cables. Before it goes anywhere, we'll clean all this up. My point is that LXI doesn't necessarily simplify cabling.

GPIB allows us to daisy-chain devices together. Ethernet, on the other hand, requires that all the cables go back to a central network hub. (In my case, a $4000 IEEE 1588 network hub.)

"Hello. It's your IT department. What are you doing to our network?"

One choice to be made in constructing an Ethernet-based test system is whether to use a private network (i.e., no connection to the outside world), or whether to hook it up to your corporate network. In some companies, plugging an LXI device into the corporate network will evoke a response similar to calling the fire department. "Bandit in cubicle 3A101! What is that device?!?! What viruses is it spreading?! Security breach! Lock the doors!" Fortunately, I don't work in such a company. But many of the more expensive new measurement instruments run some form of Microsoft Windows, and our IT department is definitely concerned about having those systems up-to-date with patches and anti-virus software.

Once you get past the IT issues, there are some practical concerns. On a corporate network, you don't always control the traffic going over your part of the network. This affects timing and synchronization, to be sure. But more practically, I've seen LXI test systems interrupted in the middle of measurement because someone decided to probe the network searching for LXI devices. The LXI Consortium recognizes the problem and has begun working on a solution (called "resource locking"), which will eventually make it into the specs.

Issues like these push engineers to use a private network, but then you'll start to miss your IT department. You'll have to provide your own DHCP server (or do without and configure static IP addresses, like I did). You'll have to provide your own DNS server (or do without, and refer to devices with IP addresses the way I did: "TCPIP::192.168.200.2::INSTR").

Summary

Key takeaways...

• LXI — Yet another way to build a test system
  
• LXI — Yes, you can talk to it from LabVIEW
  

I have a lot more I could say about LXI. Let me know what you want to hear.

Read more of this article...

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.

Read more of this article...

IVI-C and IVI-COM

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.

Read more of this article...

"NI Open"

Yesterday, I saw a new posting on the LXI Blog of Test & Measurement World's Chief Editor, Rick Nelson.

I chatted with Rick at one of this year's NIWeek parties. He's a nice guy. We talked about a variety of topics, ranging from NI's involvement in engineering education, to Lego Mindstorms NXT, to LXI.

In his latest blog entry on Hybrid Instrument Systems, he talks about how NI and other vendors are realizing that most of our users are building hybrid systems with instruments from multiple vendors, using multiple bus technologies such as GPIB, RS-232, USB, PXI, and Ethernet.

While other vendors are only just now arriving at the idea of being "open", NI's been there for a long time. If you search on the National Instruments Instrument Driver Network, you'll find drivers for over 5000 instrument models from over 200 vendors. We didn't write those drivers overnight; they're the product of a couple of decades of commitment to making LabVIEW and LabWindows/CVI open platforms for our industry.

Read more of this article...

More on Instrument Drivers

As I mentioned in my last post, instrument drivers provide a somewhat higher-level abstraction for talking to instruments. If you've used LabVIEW to talk to instruments, you probably also realize that instrument drivers come in a lot of flavors--VXIpnp, IVI-C, IVI-COM, LabVIEW Plug and Play, ... I'll try to help you sort those out.

Further, you've probably seen that NI certifies some of the instrument drivers on IDNet. What does that mean? I'll try to clarify that, too.

Keep in mind that this is a very abbreviated history, and there were a lot of details I'm leaving out...

In the beginning, instrument drivers were simple...

We had a guy sitting one room over from the LabVIEW area who wrote instrument drivers. We'd borrow instruments, bring them in house, and he'd write a few VIs to get them to take measurements. (Often, he'd also write an instrument driver for LabWindows.)

There weren't any standards, but most drivers for LabVIEW and LabWindows were pretty consistent, because there was only one guy writing them.

With a lot of help from National Instruments, the test and measurement industry started to pay more attention to software. Instrument vendors and end users started writing drivers, but there were a lot of different philosophies on what an instrument driver should look like. This made it harder for end users--they might be able to find a driver for their instrument, but they didn't always know what they were getting, or how to use it.

The VXIpnp standard

VXI (VME Extensions for Instrumentation) was an instrumentation bus standardized in the late 1980's. Out of that grew a push for more standard instrument driver software in the VXI Plug and Play (VXIpnp) Systems Alliance.

This standard specified a few items common to all instrument drivers--Initialize, Close, Error Handling... But it was pretty much measurement-agnostic. Once you got past Initialize, there was no consistency in how you configured the instrument or took a measurement.

One key aspect of VXIpnp drivers is that they require the use of VISA. This paid off in the long run, since it allows us to have a single instrument driver for an instrument with serial, GPIB, Ethernet and other connectivity.

The VXIpnp standard defined standards in multiple programming languages, including C and LabVIEW. These days, though, when you hear that a driver is VXIpnp, it is almost certainly a C driver. (Which can be used in LabVIEW by creating wrapper VIs around a DLL with an automated tool you can download from IDNet.)

The IVI League and the IVI Foundation

Skipping ahead a few years, National Instruments and some our customers created a group informally called the IVI League. The idea was to take the instrument driver software standard further--defining instrument classes, such as DMMs, Function Generators, Oscilloscopes, etc., and standardizing more of the instrument driver API.

To make progress, we knew we needed to bring in other hardware vendors, and the IVI Foundation was born. Over the course of several years, the APIs were further refined, and new instrument classes added.

IVI drivers bring a lot of advanced features. Unfortunately, they're harder to write--most are written in C or C++. This means that they're harder for end users to customize or debug. It also means that there aren't as many IVI drivers as, for example, native LabVIEW drivers.

LabVIEW Plug and Play: Bringing Back LabVIEW Drivers

As I went out and visited customers, I got a lot of feedback that they weren't entirely enthusiastic about using C-based VXIpnp or IVI drivers in LabVIEW.

IVI drivers were supposed to be more robust than earlier technologies, but customers still wanted to be able to debug their test system and step through the code. Other customers wanted to restructure the driver, or make additions to it, or optimize it. Without a C programmer on staff, this was practically impossible. IVI drivers from some other vendors didn't even include source code, so you couldn't modify them.

The LabVIEW users were willing to trade off all the IVI features for a much simpler, native LabVIEW source code instrument driver--the way we originally started. This let them make their own optimizations and enhancements.

So in LabVIEW 8.0, we rolled out the idea of "LabVIEW Plug and Play" instrument drivers. The VIs leverage the structure of VXIpnp and IVI drivers, but they fit more naturally into LabVIEW, and they include native LabVIEW source code.

LabVIEW 8 Makes Instrument Drivers Easier to Use and Easier to Develop

In LabVIEW 8, we added the Instrument Driver Finder, to make it easier to find and download instrument drivers. Our instrument driver development group started developing drivers to our improved standards. We've worked with vendors to improve LabVIEW support for their instruments.

We also made it easier for our end users to develop drivers, with the Instrument Driver New Project Wizard, and Instrument Driver VI Creator. We enhanced our Instrument Driver Development Guidelines and our Instrument Driver Templates.

In LabVIEW 8.20, we've even created a tool that lets you export LabVIEW drivers to other environments that use C.

So What Kind of Driver Should I Use?

Okay, so there's the brief history. What does it all mean? For LabVIEW users that want to talk to 3rd party instruments, you should look for Certified LabVIEW Plug and Play instrument drivers. You can use the Instrument Driver Finder, or search on your own at IDNet.

If you can't find one at NI's site, ask the vendor for a LabVIEW Plug and Play driver.

If you can't find a native LabVIEW driver, you have a few options. If you can find the instrument's command set, consider writing your own; it's not that hard.

If the vendor has a VXIpnp or IVI-C driver, they may also supply LabVIEW wrappers. Those work well, but you may not be able to modify/debug the driver.

If the vendor has a .Net or IVI-COM driver, you can use it in LabVIEW using our native .Net and ActiveX programming.

Future Topics

Okay, I didn't cover a couple of things I said I would...

• What does "Certified" mean?

• What's the difference between IVI-C and IVI-COM

I'll work on those in upcoming posts.

Read more of this article...

So Many Choices...

So many things to write about...

There are so many topics I could start this blog with...

• Discussing the latest instrument control features of LabVIEW 8.0 and 8.20.
• Building test systems--especially hybrid systems combining instruments from multiple vendors, all using different bus technologies.
• A look at new additions to your measurement toolboxes, such as PXI Express, LXI, and synthetic instruments

And the list goes on and on. But I feel there's some groundwork I need to lay, for those of you who may be somewhat newer to LabVIEW Measurements.

So many ways to talk to instruments...

One of the good things about LabVIEW is that it is a very rich environment. One of the bad things about LabVIEW is that it is a very rich environment. We give you several different ways to talk to 3rd party instrumentation, and it's sometimes hard to sort out all the options. In this article, I'll explain some of the options and give advice for different situations.

As I'm sure most of you understand, test programs talk to instruments using low-level commands peculiar to each instrument. Many instruments are programmed through an ASCII language called SCPI. Some are programmed by writing to registers mapped into a program's address space. Some use proprietary protocols.

Fortunately, if you can find out the language that an instrument speaks, you can talk to it from LabVIEW. Vendors usually include their particular command set as part of an instrument's documentation. Most GPIB instrumentation uses SCPI, so I'll use that as an example.

LabVIEW 7.0 introduced a feature called Instrument I/O Assistant (IIOA), which makes it easy to create and test VIs that send commands to and read responses from instruments. You can place an IIOA block on your diagram, select the instrument you want to send a command to, and type in the command--e.g., "CONF:VOLT:AC" might be the SCPI command to set a multimeter to measure AC volts. Test it out, click OK, and you have your first instrument control VI.

VISA: A software standard for instrument communications

When I first started working on LabVIEW, we had two sets of icons for instrument communications... the GPIB VIs and the Serial VIs. Back then, most instrumentation had one or the other kind of port on the back of it. These days, it's not uncommon for an instrument to also have a USB port or an Ethernet port. If you throw in buses found inside PCs, we've also seen NuBus, AT-bus, EISA-bus, PCI, PXI, PCI Express, PXI Express, VME, VXI...

But, we didn't want to add a new set of icons to LabVIEW every time a new bus technology came out. In the early 1990's, National Instruments and other vendors (part of the VXI Plug and Play Systems Alliance) created VISA (Virtual Instrument Software Architecture).

The full story of VISA is best left for others, but suffice it to say that it lets us have one set of icons in LabVIEW that knows how to talk to a bunch of different buses and instruments.

We still have GPIB functions in LabVIEW. They're useful for legacy applications, and they're easier to use if you're trying to do advanced, low-level control of GPIB. But for most instrument control applications, VISA is a better approach.

Interestingly, we (more specifically, I) removed the older serial functions from LabVIEW in version 7.0. You can still do RS-232/RS-422 serial I/O in LabVIEW; you just use VISA to do this. The rationale for this decision could be another lengthy post. In short, NI's VISA implemented serial I/O faster and better than the old code, so we made the switch. But we still hear complaints about my decision.

Instrument Drivers make programming easier

An "instrument driver" is a collection of VIs that provide a higher-level interface to programming an instrument. Instead of having to remember several low-level commands to configure a multimeter or oscilloscope, you can use a single high-level function called "Configure Measurement".

Instrument drivers come in a lot of different flavors. LabVIEW Plug and Play, IVI-C, IVI-COM, VXIpnp, etc. I'll sort all those out in a future post.

The main point I want to make here is that using an instrument driver can save you a lot of time. If you can find an instrument driver for your instrument, you're almost always better off using it than using low-level SCPI commands.

LabVIEW 8 adds an Instrument Driver Finder which can help you search for instrument drivers. You can also visit IDNet, an instrument driver repository that contains drivers for thousands of instruments from various vendors.

Look for more on instrument drivers in a future post.

---

Post your comments. What do you want me to write about?

Read more of this article...

Who Am I? Why Am I Here?

My name is Brian Powell, and I'm a software architect on the LabVIEW R&D team in Austin, Texas. I've been with National Instruments since early 1988. So what have I been doing all this time?

LabVIEW is a graphical programming language that scientists and engineers use to design and develop test, measurement and control applications. LabVIEW is used for a seemingly infinite variety of applications by thousands of different customers. I've had the great fortune to visit many of our customers--including those developing spacecraft, performing particle physics research, developing automotive systems, manufacturing cell phones, and even a customer with computerized saws making furniture.

In my time at NI, I've essentially only had one job--developer on the LabVIEW team. On the other hand, I've had many different roles to play...

• Macintosh programmer (that's what got me the job)
• Email administrator (...!ihnp4!ut-sally!natinst!brian)
• USENET administrator
• Network administrator
• SunOS/Solaris programmer
• Web administator
• Project manager
• Group manager

Of course, my "real job" is adding features to LabVIEW and trying to make it a better product.

I work in the part of LabVIEW that's responsible for making all the I/O (NI and 3rd party) work well in LabVIEW. "Work well" means a lot of things--easier, faster, more powerful, more consistent. Since LabVIEW's all about the I/O, our group is often a vortex. If somebody inside or outside the company wants to integrate into LabVIEW, sooner or later, they'll almost certainly come through us.

I started this blog for a variety of reasons. Over the years I've learned a lot, and I feel I have advice and opinions that could be useful to the LabVIEW community. I often hear from users who ask about how best to write something in LabVIEW. I hear from 3rd party instrument vendors about how best to integrate into LabVIEW. I hear from users who want to know why we changed something, or why something behaves the way that it does.

So I hope I can provide a little insight, and that this blog turns out to be useful and maybe a little entertaining. If you have ideas you want me to talk about, please post comments or send me an email.

Brian

Read more of this article...