Migrating to Ethernet
Preserve code written for IEEE 488 instruments when you transfer to a new bus.
Brian Powell and Dany Cheij, National Instruments, Austin, TX -- Test & Measurement World, 10/1/2004 2:00:00 AM
IEEE 488 and RS-232 ports have sustained instrument communications for many years. But RS-232 is too slow for many test applications, and IEEE 488—although it is robust and has sufficient speed—requires the use of add-on cards.
Ethernet and USB high-speed serial ports are emerging as new buses for instrument applications. These ports are standard peripherals on new PCs, and they are also starting to appear in test instruments from some manufacturers.
Using Ethernet and USB high-speed ports is fairly easy. Because of their supporting software infrastructure, you can use them without understanding their low-level drivers and function calls. Yet, there is a minor complication. Ethernet and USB were designed for communication between PCs and peripherals such as printers, cable modems, and external drives, but not for communication between PCs and instruments. When used for instrument control, these buses must handle interrupts and other instrument functions through software that the parallel IEEE 488 bus handles through hardware.
You can set up instrument-control functions for Ethernet and USB by employing the Virtual Instrument Software Architecture (VISA), which was first designed as a VXI tool. In the mid-1990s, the VXIplug&play Systems Alliance developed the VISA application programming interface (API) for instrument control and communication through IEEE 488 and RS-232, and it has become the industry standard for programming instruments over those two ports.
Generally, VXIplug&play instrument drivers send commands to the buses through VISA, although some test applications bypass instrument drivers and communicate directly to VISA. VISA then communicates with low-level drivers such as those for IEEE 488 interface cards, serial ports, TCP/IP stacks, and USB.
After adopting VISA, the VXIplug&play Alliance expanded it to cover Ethernet-based instruments. The VXI-11 standard enhanced VISA by standardizing both the low-level TCP/IP communications protocol and the higher-level APIs (Ref. 1). In 2003, Agilent Technologies and National Instruments enhanced their versions of VISA to provide communications to instruments over USB using the same API (Ref. 2).
Higher level
Instruments generate interrupts when they have data to send to a PC, and PCs issue abort commands to terminate measurements. IEEE 488 uses hardware signals to generate and service interrupts, but Ethernet and USB are serial buses—they lack IEEE 488's dedicated interrupt lines. VXI-11 defines how VISA implements these functions over Ethernet and USB. (For the remainder of this article, we won't mention USB, but you can use the same VISA API with that bus.)
|
| Figure 1. VXI-11 defines TCP-IP connection channels between a computer and an instrument. |
Figure 1 shows the three TCP/IP communication channels in VXI-11. The core channel passes messages between the PC (the controller) and the instrument. Just as with IEEE 488, you can send a "*IDN?" query to an instrument and read a response containing its identification string. The Abort channel lets the controller stop an active operation. The instrument uses the Interrupt channel to request service from the PC.
Simple operations such as polling an instrument for a measurement may never use the Abort and Interrupt channels, but you need them for robust behavior. Dedicated hardware lines in the IEEE 488 bus let instruments interrupt communications and request service. With VXI-11, software must emulate interrupts, aborts, and triggers that IEEE 488 implements with hardware.
Suppose you set up a triggered waveform acquisition on a scope. The controller requests the waveform from the scope and then realizes that the trigger is set up incorrectly. You now need to abort the request for the waveform.
In this case, a computer sends a message over the Abort channel to tell the instrument to cancel the pending request. In another scenario, you could set up a waveform acquisition and ask the instrument to send a notification on the Interrupt channel when the data becomes available. VXI-11 supports both methods of programming.
Under the hood
To communicate with instruments over TCP/IP, VXI-11 uses an open networking standard called Remote Procedure Calls (RPC). RPC standardizes how TCP/IP establishes the three connection channels. An additional standard, eXternal Data Representation (XDR), defines how data is formatted when transmitted between the PC and the instrument.
When a PC wants to write a command such as "*IDN?" to an Ethernet-based instrument that supports VXI-11, it connects to the instrument and asks it to run a TCP/IP "device_write" procedure with a parameter that says "*IDN?". VXI-11 devices implement a handful of these remote procedures, most of which are familiar to IEEE 488 users. They include Write, Read, Trigger, Clear, Read Status Byte, and Enable Service Request. If your instrument doesn't support VXI-11, then it either uses low-level TCP/IP commands or implements its own protocol.
Because VXI-11 is based on RPC, and RPC is based on TCP/IP, you can make direct calls from your applications program to a TCP/IP stack, but you need to understand how RPC and XDR work. Such knowledge must include familiarity with all the opcodes and data structures for calling the remote procedures. Figure 2 shows the number of low-level TCP/IP packets you need for a simple instrument query. This example (created in LabView) needs several TCP/IP packets to open the RPC connections for the Core and Abort channels. Once the channels are open, communications are rather efficient.
|
| Figure 2. A simple write-read sequence requires 31 TCP/IP packets. |
Standard API
As mentioned earlier, VISA is the standard API for communicating with VXI-11 devices. VISA lets users focus on Writes and Reads without having to worry about remote procedure calls and TCP/IP networking. In addition, VISA isolates the program from the bus an instrument uses (IEEE 488, RS-232, Ethernet, or USB).
In Figure 2, only the resource descriptor (TCPIP::10.0.41.6::INSTR) is unique to TCP/IP communications. The program passes it to the "VISA Open" function to select the communications port. If the program were using IEEE 488 instead, you'd simply substitute a resource descriptor such as "GPIB::22::INSTR" and the rest of the application would continue to work.
|
| A host and instrument must establish an RPC connection to transfer data. |
Although you can communicate with an Ethernet-based instrument using low-level TCP/IP commands, you'll find it challenging. Protocols such as VXI-11 simplify communications and shield you from the intricacies of the bus. By using an API such as VISA, you can focus on measurements instead of spending time learning networking protocols.
The convenience of having a bus-independent API such as VISA becomes more apparent through instrument drivers. Instrument drivers are a set of software routines that control a programmable instrument. They simplify instrument control because they aggregate multiple low-level VISA commands into high-level routines such as "Initialize" or "Read." An instrument driver based on the VISA API can support both IEEE 488 and Ethernet (VXI-11) interfaces. This lets you write the same application program to communicate with the instrument through either bus.
| References |
|
Map the route to USB instruments
05/01/2003Get off the shelf
03/31/2004VXI keeps hanging around
03/31/2008IEEE 1394, USB, or both?
11/01/2001IVI drivers: Slower but simpler
01/31/2003
-
FLIR offers IR camera for under $3000
-
Don't let the economy compromise quality (Guest commentary)
-
Danaher speeds up restructuring, acquires life-sciences businesses
-
Agilent’s Cover-Extend technology eliminates need for physical test points for in-circuit test
-
So many combinations: Testing a switch-matrix board
View All Webcasts
