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.
8 comments:
Hi Brian,
You brought out some good points like " $4000 IEEE 1588 network hub" and "IEEE-1588 synchronization works best in small closed networks" and I'd like to comment on a few.
First, I was surprised to know that a 1588 hub costs that much. On the second comment, our ATEs are usually a small closed networks and the flexibility to go site or world wide is good during certain phases of the project. It's good to have options. So the concern of timing and synch are well noted, but we manage that, while having the option to network when needed.
I definitely think ethernet (VXI-11 or LXI) has a lot of promise. GPIB is present in legacy systems & current instruments, but today I will not pick it and would look at ethernet first, 232 (common) or USB if it provides plug & recognize and if this feature benefits the application. I am aware of the speed and latency tradeoffs with each option. My take is LXI is definitely a good thing and seems to have some big name supporters. Maybe if NI (and other companies) would support and get involved in this standard, issues could be ironed out and the standard made better.
On your last point, NI is involved with the LXI standard (as well as related standards such as IEEE-1588 and VXI-11). We have engineers who attend LXI meetings and participate in (seemingly daily) conference calls.
The LXI Consortium was created by several of our competitors. They aren't necessarily trying to make LXI difficult to use in LabVIEW, but they don't always understand how a LabVIEW user's needs are different than a C# programmer's needs. We've done work behind the scenes in the LXI Consortium to help improve the LXI experience for our customers.
Thanks for the clarification. I am glad to hear that Labview is involved. However, it seems like National Instruments is dragging its feet on the LXI standard and even making LXI look bad. For example, you says its okay to build a system with LXI, but then you show a picture in your blog intentionally making LXI look bad.
I would just like to see Labview say that is openly supports LXI so I know it is okay to build my system with your tools. From the LXI blogs, other software supports LXI today like VEE, Matlab, and Measurement Foundry. I can't see why Labview just can't do the same.
Douglas
Fair enough. Keep in mind that the opinions I write in this blog are mine, and not NI's.
I have a couple of my own comments about yours...
"[NI] is dragging its feet on the LXI standard" -- can you explain more what you mean by this? Is there a particular part of the standard where you think NI slowed things down? I've only been involved in LXI for the last few months, so I'm not sure what discussions you are referring to.
"you show a picture in your blog intentionally making LXI look bad" -- I think I prefaced that picture with "Here's an example of why no one pays me to build test systems...", but I admit it was in response to marketing I've seen that says cabling is so easy with LXI. With my cabling skills, I would have done an equally bad job with a GPIB test system. It would have required fewer but thicker cables. Getting back to my original point, LXI shares these issues with other buses; it didn't make cabling easier for me in this test system.
"From the LXI blogs" – out of curiosity, what blogs are you talking about? I know that somebody sponsors an LXI Blog at the T&M World web site. I didn't see much of anything in that blog about these software packages and their support for LXI. Post a link; I’d like to read what others are saying.
A small clarification, I think you meant to mention Data Translation's Measure Foundry, not Measurement Foundry.
I do try to keep up with VEE. VEE 7.5 added really good support for NI hardware, and I’m interested to see how the next version will improve LXI support.
"I would just like to see LabVIEW say that [it] openly supports LXI so I know it is okay to build my system with your tools." -- All I can say is that LabVIEW is what I would use. But I would more strongly encourage a system designer to step back and look at all the options. For hardware buses, I would not just look at LAN, but also GPIB, Serial, PXI, VXI, etc. Each bus has strengths and weaknesses. The same is true for specific measurement devices. The same is true for software development environments. The same is true for operating systems. I'm obviously biased, but I think NI's software and hardware give you a lot of flexibility that don't commit you to a single system architecture.
Hi brian,
i am working on test and measurement of RF systems and we are using gpib as interface. we are using instruments from agilent, tektronics, R&S etc.
i was trying to communicate with the Tektronics RSA6100 series real time spectrum analyzer over the ethernet using VISA write but unable to do it.
VISA find resource is finding the RTSA as GPIB device but not as an ethernet device. instead it is detecting a default resource with an ip address which no device have.
what can be the problem??
Hi, anonymous. I'll try to help you.
The RSA6100 family is not certified as LXI-compliant. However, it almost certainly behaves in a similar way, using the VXI-11 network protocol.
What software are you using on your PC to talk to it? Are you using NI VISA? Agilent VISA? Tektronix VISA? What programming language(s) are you using?
If you can fill in more details (feel free to post them here or contact me directly), I'll try to help.
i am using Labview 2009 and NI VISA.
i have also tried with labview 7.1.
i have also tried to communicate with the RSA6100 using the NI Measurement and explorer utility, but was unable to do so
The first thing to confirm is that the RSA6100 is running the VXI-11 server. As I recall, this RSA is running a Microsoft Windows operating system. If so, I think you should see an icon in the notification area of the system tray (on the RSA itself, not your PC) that shows the status of the VXI-11 server.
Second, I would confirm the IP addresses are correct. If you have an IT department, they may be able to help you more quickly than I can. Otherwise, post the IP address, subnet mask, and gateway address of both your PC and your RSA, and I'll take a look.
How are the RSA and PC connected? Do you have a network hub? A router?
You might also check to see if you have a network firewall that's preventing communications. This might be the Windows firewall on your PC or the RSA, or it might be something configured in a network router between them.
Post a Comment