Sunday, September 17, 2006

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


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

Tuesday, September 12, 2006

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 NameDescription
IviScopeTVTriggerPolarityPositiveConfigures the oscilloscope to trigger on a positive video sync pulse.
IviScopeTVTriggerPolarityNegativeConfigures 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 NameDescription
TekScopeTriggerVideoPolarityInvertedInverted. Sets the oscilloscope to trigger on a positive video sync pulse.
TekScopeTriggerVideoPolarityNormalNormal. 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...

Thursday, September 07, 2006


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