AutoTestCon 2008

As I mentioned in an earlier post, I was at AutoTestCon in Salt Lake City a few weeks ago. This was my first visit to this MIL/AERO conference and tradeshow.

I was greeted to the Salt Palace Convention Center by banners with images of fighter jets and bombers over Monument Valley and Delicate Arch.

I was there to give a presentation on IVI, be part of a panel discussion on LXI, and to support a demo for the LXI Consortium...

Here's a photo of the demo I built for the consortium, using a Rohde & Schwarz FSL Spectrum Analyzer, a Keithley 2910 RF Signal Generator, two Agilent E5818A Trigger Boxes, an NI 8353 quad-core 1U PXI Controller, and NI LabVIEW 8.6.



The other demo in the booth consisted of Matlab and image processing software from The Mathworks, Agilent E5818A Trigger Boxes, and 1394 cameras from Point Grey Research. Colloquially called "the bouncing ball demo", it used a military grade Playskool Busy Basics Busy Popper for projectile measurements.



Okay, the part about "military grade" was a joke. The demo was there to make noise and entice people into the booth. Shown in the photo are Conrad Proft, from Agilent, and Rob Purser, from The Mathworks.

Both demos showed LXI features such as IEEE 1588 timing and distributing triggers across a network.

---

On Monday, I gave a presentation about IVI instrument driver technology at one of the seminars. This was just a basic introduction into what IVI drivers are, and an update on the status of current work in the IVI Foundation.

The tone was set for this presentation a few seconds into my talk. One attendee raised his hand and said, "IVI drivers don't work."

"I see it's going to be a tough crowd", I replied.

In this particular case, the user had obtained several IVI-COM drivers from his instrument vendor, and all but one failed to communicate correctly with his instruments. He had also received an IVI-C driver for an instrument from a different vendor, and he was unable to make it work until he got National Instruments involved to fix it for him.

This is a good point for me to point out that you don't have to depend on your instrument vendor for your instrument drivers. The National Instruments Instrument Driver Network (IDNet) contains instrument drivers for thousands of instruments from hundreds of different vendors, including IVI drivers, LabVIEW Plug and Play drivers, and VXIplug&play drivers.

Many of the drivers on IDNet are marked as "NI Certified", which means...

Certified instrument drivers comply with instrument driver standards including programming style, error handling, documentation, and functional testing. Certified drivers ensure consistency among instrument drivers and, therefore, improve ease of use. They also provide source code so that you can modify, customize, optimize, debug, and add functionality to the instrument driver. All National Instruments certified instrument drivers receive NI support.

---

I was also on a panel discussion about LXI. We presented to about fifteen people.

A week later, we recorded a webcast for T&M World Magazine with the same material. You can view a replay of the webcast by registering on the T&M World website.

We had time for questions and answers during both versions of the presentation. Additional questions from the webcast will eventually be posted with answers on the LXI website.

Interestingly, most of the questions at AutoTestCon related to GPIB. Conrad Proft, from Agilent, had slides that showed examples where LXI works better than GPIB (over long distances) and RS-485 (cabling).

One question was whether companies are going to continue to support GPIB. Conrad from Agilent voiced his company's continued commitment to GPIB. I added that I believe that many people are still building GPIB-based test systems, and that NI will continue to support our GPIB users. (Later that week, NI announced our new PCI Express GPIB controllers that support a nearly 8 megabyte/second transfer rate, are RoHS compliant, and use only 1.1W of power.)

Another audience member, perhaps a little caught up in the excitement of LAN-based instrumentation, asked, "Why would anyone still use GPIB? It's slow. The cables are so inflexible."

My jaw dropped at this. I bet if you polled all the AutoTestCon attendees, just about every one of them is using GPIB, and is going to continue to use GPIB. So my answer began with, "Because it just works!".

"The GPIB cables are shielded and have rugged connectors that screw in and don't have plastic tabs that break off."

[Bringing it back to LXI] "...the message of the LXI Consortium is that it's important to ensure that LXI works well with other buses."

The reality is that our users are going to develop "hybrid" systems, using a mix of bus technologies. Every bus has pros and cons. GPIB has low communications latency and is rugged. LXI has cheaper cabling and works well over extraordinarily long distances. PXI and PXI Express have high communications bandwidth and low latency.

And that's why it's my job at National Instruments to help ensure that all forms of I/O work well in LabVIEW.

Read more of this article...

AutoTestCon 2008 in Salt Lake City

I'll be in Salt Lake City next week, September 8-10, for AutoTestCon.

AutoTestCon is a large Mil/Aero conference and trade show sponsored by the IEEE.

I'll be doing a couple of presentations...

On Monday, I'm presenting as part of a seminar entitled, "VXI, PXI, IVI & LXI Standards Improve ATE Systems Design". I will be presenting the part about IVI. I'll cover what IVI is, the current state of IVI, future work, as well as technical informationi on configuration, the differences between IVI-C and IVI-COM, and how to use class and specific drivers together.

On Wednesday, I will be part of a panel discussion on "Test Applications Using LXI Instruments". Hosted by Test & Measurement World chief editor Rick Nelson, the panel plans to share some of what we've learned over the past three years creating multi-vendor LXI-based test systems.

Read more of this article...

NIWeek 2008

It's Monday of NIWeek 2008, so it's a tradition for the Austin American-Statesman (the local newspaper) to have a nice article about NI. Today's was about Green Engineering.

Today is Alliance Day, and the full-blown conference starts tomorrow.

I'll be presenting again this year, on Thursday...

My topic is about using NI hardware and software products to work with LXI-based test systems.

I'll be around the convention center all week, including the LAVA dinner Tuesday night, and the conference party on Wednesday. Feel free to find me and say hi.

Read more of this article...

Thoughts on Network Protocols for Instrumentation

Among my other responsibilities, I still hang out with the LXI crowd. Lots of conference calls, and a quarterly face-to-face meeting. (Thank you, TestForce, for hosting our recent meeting in Toronto.)

Following up on my earlier blog post, National Instruments did join the LXI Consortium at some point (last year, I think). I believe that having one network-instrumentation standard to follow is better than having many, and the technical side of the consortium is constantly working to devise solutions to limitations inherent in a network-based test system.

There are a variety of challenges revolving around the fact that LAN opens up the door to having more than one "controller" in a test system.

In a test system using RS-232 or USB, for example, any single device talks to only a single "controller"—typically the test system's PC. A GPIB system is a form of network, but there's always one "controller in charge". Nobody can easily intrude into the test system.

Is this a "feature", or a "limitation"? It all depends on the test system. What if you wanted to see test data from the outside world? Today, you'd probably put a network connection on your test PC, and let it serve up data through the LabVIEW Web Server, or store data into a corporate database. Nobody could talk to the instruments directly; they would always go through the PC.

But an alternative that LXI allows is to connect your private test network to the rest of your company's intranet (or the entire internet, if you want). This allows others to interact directly with the measurement instruments. You probably wouldn't want this feature in all test systems, but it opens the door to some interesting possibilities.

Even if you don't connect your test network to the internet, you might still want to have more than one test PC talking to the devices. Or one grand vision of the consortium is that instruments can control other instruments. How does an instrument manage multiple connections from multiple controllers at once? Does this sound complicated? It is.

And this is where the LXI Consortium comes in. What can the consortium do to make it "safe" to have more than one controller on your network?

There are many aspects of this that the consortium is working on—defining behavior when there are too many connections for an instrument to handle, for example. One particularly challenging problem is how to "reserve" or "lock" an instrument in your test program so that nobody else comes in and changes settings in the middle of your test.

It's worse than that, really. Just discovering instruments on your network can have the accidental side effect of interrupting a test program. And it's especially this kind of inadvertent access to a test instrument that the consortium is trying to resolve.

One step in this direction was announced in the LXI 1.2 standard. There will be a new mechanism for discovering LXI devices that is less obtrusive than the current approach. In the future, when instruments are available that support the next version of the LXI standard, this very common form of inadvertant access should be solved for future test systems.

But there are still challenges with test systems with more than one computer or instrument trying to talk to a single device at the same time. For that, we really need to be able to reserve the instrument for exclusive use by a single test program (or perhaps even a single part of a larger test program).

This problem has been solved before in this domain. In 2004, I helped write an article for T&M World entitled Migrating to Ethernet. I discussed the VXI-11 protocol for communicating with instrumentation over Ethernet.

Because VXI-11 defines processing on both the host (PC) and client (instrument), it is able to provide a way to reserve or lock the instrument in a test program. With VXI-11 devices, the VISA commands viLock and viUnlock can be used to lock the instrument so that it only responds to the program that has the lock.

However, VXI-11 has kind of fallen out of favor with instrument vendors. One reason is that it requires a fair amount of processing horsepower inside the instrument. VXI-11 is based on a technology called RPC, or Remote Procedure Calls. With RPC, much of the processing happens on the instrument, requiring more processing power, more memory, and thus, higher overall cost.

Instrument vendors want to move to simpler protocols. The consortium therefore needs to take a fresh look at instrument locking, and hopefully come up with a proposed solution in the 2009 or 2010 versions of the LXI standard.

Until then, fortunately, most LXI instruments continue to support VXI-11 and you can use viLock or viUnlock (in LabVIEW, they are called "VISA Lock Async" and "VISA Unlock") to lock instruments in your test system.

One caveat is that IVI drivers do not support the same kind of locking. You need to have access to the VISA session to properly lock the device. This is one of the benefits of using a LabVIEW Plug and Play (or for C users, VXIpnp) driver. Since these kinds of drivers use the VISA session directly, you can easily add VISA Lock and VISA Unlock calls to your program without major rework.

Stay tuned as the standards evolve.

Read more of this article...

My NIWeek 2007 Sessions

I hope you are attending NIWeek, and that you are planning to attend at least one of my NIWeek presentations...

• Software Engineering - The NI Way


• Using LabVIEW in an LXI-Based Test System


• Head-to-Head High-Speed Bus Comparison: GPIB, PCI, PCI Express, USB, and Ethernet/LAN

Read more below for details on each presentation...

Software Engineering - The NI Way

Wednesday, 3:30 PM, Room 12A

Join me for an interactive discussion about how NI develops software. When I first joined NI nearly 20 years ago, our software development process was, shall I say, "underdeveloped". Fortunately, we've been improving ever since.

I'll talk about how our process has evolved as our team and code have gotten bigger. I'll talk about and demo some of the tools we use.

This topic is significantly more interesting with audience participation, so bring your own thoughts and stories about how you develop software.

Using LabVIEW in an LXI-Based Test System

Wednesday, 4:45 PM, Room 17A

LXI is a relatively new standard for LAN-based test and measurement instrumentation. As many of you know, I represent NI at LXI Consortium meetings. You may have read my earlier blog postings about What is LXI? and LAN is Simple, Right?

In this presentation, I'll show how you can use NI hardware and software to control an LXI-based system. I've put together a system containing LXI devices from Rohde & Schwarz, Pickering Interfaces, and Agilent. (Thanks to the vendors who loaned me their equipment!)

This NIWeek presentation is heavy on demos and light on slides. I'll show you everything from simple instrument communciations to advanced synchronization and timing.

Head-to-Head High-Speed Bus Comparison: GPIB, PCI, PCI Express, USB, and Ethernet/LAN

Wednesday, 10:30 AM, Room 17B

Thursday, 2:15 PM, Room 13B

The typical test system these days includes instrumentation with a variety of interfaces. You might have a mix of simple PXI devices, legacy GPIB instruments, and perhaps a LAN or USB device thrown in. This presentation will shed some light on the strengths and weaknesses of various buses, including performance, cost, and ease of use.

Read more of this article...

NIWeek 2007

NIWeek 2007 is fast approaching on August 7-9. If you use NI products (or are thinking of using them), this is an awesome event. Dozens of technical sessions, amazing keynotes, and scores of exhibitors. In addition, we have special summits for Graphical System Design, RF and Wireless Communications, Sound and Vibration, and Vision applications. Register now at niweek.com.

Staying informed during NIWeek

• Whether or not you are attending NIWeek, watch the NIWeek Blog by Michael Aivaliotis. Videos and stories throughout NIWeek.


• The official NIWeek Twitter link can keep you informed of late-breaking NIWeek news. Or maybe you can just twitter each other during my presentation about how great it is. ;-)
  

Speaking of my presentations, I have three this year...

• Software Engineering - The NI Way


• Using LabVIEW in an LXI-Based Test System


• Head-to-Head High-Speed Bus Comparison: GPIB, PCI, PCI Express, USB, and Ethernet/LAN

I'll post more information on these as we get closer.

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

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

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