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