When a new instrument architecture becomes available, one of the biggest challenges is figuring out how to integrate it with your existing equipment. This integration hesitation helps explain why system creators continue to purchase large quantities of GPIB-based instruments even when LXI and modular alternatives exist for almost any instrument type. An important underlying cause of that hesitation is the beauty of software compatibility with existing test code.
In recent years, instrument vendors have gotten better at offering compatibility modes that allow you to move from an old instrument to a newer, faster, more capable model. As a user, you probably follow a two-step migration process. First, you decide to evaluate the new instrument but keep it on the same interface. Once you are convinced that your test programs will migrate without too much difficulty, the second step is deciding if or when to move to the new LXI interface.
Because this is a two-step process, there’s a high probability that you won’t ever complete the migration. For example, if performance is good enough, then you will keep the old interface along with the old program when you build a new test system. This approach probably won’t maximize the potential performance gains from the new instrument, but you won’t—and shouldn’t—waste hours, days, or weeks writing and debugging code to make it work with the new interface.
The LXI standard was designed to minimize the size of this second step. Part of the LXI specification included a GPIB compatibility mode called VXI-11. This actually is contained within the IVI foundation but was included as a requirement of new LXI instruments.
In addition to bringing GPIB-compatible programming to the LAN interface, VXI-11 is extremely convenient. For example, if a test program uses a declaration to set instrument addresses, only a simple substitution of a VXI-11 address for the GPIB address is needed to migrate the code. Assuming your new LXI instrument supports the same command set as the GPIB instrument it replaces, the code migration may be complete.
Your migration may be incomplete because VXI-11, as implemented in LAN/LXI instruments, has two limitations that can be deal breakers:
- VXI-11 generally is implemented on a LAN remote procedure call (RPC) layer. This adds a translation layer to the underlying code, adding overhead to instrument communications. As a result, the actual I/O performance may be disappointing.
- VXI-11 does not implement interrupts. If the existing test code implements SRQ interrupts in GPIB, then reprogramming will be needed to achieve the same functionality.
If an instrument’s measurement time is long compared to its communications time, the first limitation is not an issue. If the measurement time is short, you probably won’t use VXI-11. If your program relies on interrupts, the second limitation dictates that you’ll need to reprogram at least the parts of your code that manage the interrupts.
Fortunately, a new protocol has been approved. The High-Speed LAN Instrument Protocol (HiSLIP) addresses the two limitations while retaining compatibility with GPIB programming. It also does everything VXI-11 can do plus more.
HiSLIP is built on a sockets foundation, letting it take full advantage of the performance potential of the LAN link. In terms of performance, HiSLIP generally is equal to or faster than sockets, and it outperforms VXI-11 across the board.
This completes the computer end of the chain. Now instrument vendors will need to support the protocols on their instruments before you can create systems based on the protocol. This should be relatively easy to implement on new instruments but might be more problematic for existing LXI instruments. At a minimum, it will require updates to instrument firmware, software, or both.
Once HiSLIP is firmly in place, the move to LXI will become fast and easy—and integration hesitation should be replaced by migration acceleration. It isn’t here yet, but at least we can see how to get there.