"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...