Programming preliminaries.

In some situations, working with an LXI instrument can be extremely easy. Make an Ethernet connection between a PC and an LXI instrument, enter its IP address into a Web browser, and begin some simple work on the Web pages embedded in the instrument such as taking a reading.

This approach, however, is useful for only the most basic applications and might not work for some LXI instruments. Before you can start to program an LXI test system of any realistic complexity, you must do some minor prep work involving drivers and other support software.

In the process, you'll run into a number of standards and terms that might not be familiar. Keep in mind, though, that much of this software functions behind the scenes so you won't have to concern yourself with what is going on at the low level. Nevertheless, knowledge of what is going on is important (FIGURE 1).

Start With Drivers

All LXI instruments are programmable somehow. But it's not always clear what options you have and how to choose among them.

The LXI standard mandates that every LXI instrument must have an Interchangeable Virtual Instrument (IVI) driver. The IVI Foundation defines a standard driver application programming interface (API) for programmable instruments.

Currently, there are two IVI driver formats: IVI-COM for working with COM-based development environments and IVI-C for working in traditional programming languages. However, most LXI instruments can be programmed in ways besides IVI, so it's not mandatory to work with an IVI driver.

Instead, developers can use other driver technologies or work directly with SCPI commands. This is good news for users of Linux and other operating systems because IVI drivers are certified only for Windows.

Most programmable instruments speak a language called the Standard Commands for Programmable Instrumentation (SCPI). SCPI defines a standard command syntax rather than a standard set of commands. For instruments that support SCPI, the command language works regardless of the bus being used, whether it's GPIB, RS-232, or Ethernet. But SCPI doesn't define how you send those commands.

Without such higher-level APIs, users would have to write code specific to each bus. For instance, if you wanted to write to a serial device, you could look up the OS's serial API, such as CreateFile on Windows, to send and receive ASCII strings. If you wanted to write to a GPIB device, you could use the vendor's driver that came with the GPIB card. To write to a USB device, you could learn the OS's USB API and implement a USB test and measurement class layer. And for a VXI-11 device such as an LXI instrument, you could use remote procedure calls (RPC) with an RPC library.

Fortunately, there is a higher-level API called the Virtual Instrument Software Architecture (VISA) that abstracts the different buses into a single unified API. VISA allows you to send SCPI commands to an instrument in an OS-independent, transport-independent way. In the case of LXI, VISA eases the communications between the Ethernet controller in a PC and an LXI instrument.

Over Ethernet, VISA supports two different technologies for communications. One is a protocol called VXI-11 defined in 1995 by the VXIbus Consortium. This standard isn't specific to VXI hardware. In fact, it's become the de facto standard for all Ethernet-based instrumentation. It supports concepts familiar to users of GPIB such as the capability for instruments to request service and for computers to interrupt a measurement in progress.

The LXI 1.0 and 1.1 standards required that LXI instruments implement basic VXI-11 capabilities for instrument identification. This will be changed in future versions of the LXI standard.

The other network protocol supported by VISA is a raw TCP/IP socket, which you can use with instruments that do not fully implement VXI-11. Some instrument designers forgo the complexities of VXI-11 and only implement a simple network port through which you can send commands and receive responses. This usually means that those instruments do not implement an asynchronous notification mechanism such as service requests.

[FIGURE 1 OMITTED]

VISA also can communicate over other buses. The common implementations of VISA know how to talk to instruments over GPIB, RS-232, USB, PCI/PXI, and VME/VXI.

With VISA, you can concentrate on writes and reads without worrying about RPCs, serial I/O, or lower-level bus technologies. Further, VISA isolates the user software from the instrument bus so users can easily combine LXI instruments with GPIB, serial, or USB instruments in hybrid systems with little effort.

As for commercial VISA implementations, the two most popular are NI-VISA from National Instruments and Agilent VISA. NI-VISA is available as a separate product and included with the company's instrument control hardware such as GPIB controllers and various software development environments. Agilent VISA comes as part of the Agilent 10 Libraries Suite, available as a separate product, and with the company's hardware products.

Neither implementation is free. You must either purchase a license for it or use one of the companies' other products to be properly licensed. Suppliers of other application development environments (ADEs) sometimes assume you have a VISA that comes with the instruments you own.

[FIGURE 2 OMITTED]

IVI Abstracts Instrument Classes

Where VISA's role is to abstract the communications layer, IVI's role is to remove the differences between models of the same class of instrument. For example, the IVI-Scope API presents a standard, interchangeable API that lets you program most commands that most oscilloscopes implement. IVI uses VISA as its transport layer; in other words, IVI calls VISA, which then calls lower-level APIs.

Besides installing an instrument-specific IVI driver, you also must load a set of IVI Shared Components. Because there are some key components to all implementations, the IVI Foundation created these shared components to make it easier for users when they combine drivers and software from multiple vendors.

The components provide services to drivers and clients that need to be common such as the administration of system-wide configuration. They generally are installed with the development environment or as part of an instrument driver's installation procedure. If not, they can be downloaded separately from the IVI Foundation website.

When speaking of shared components, you'll sometimes see a reference to the IVI Configuration Store, which is accessed only through the IVI Configuration Server, one of the shared components. The Configuration Store publishes the list of instruments supported by a particular driver.

In addition, an end user can create an alias for an IVI device through utilities such as NI's Measurement & Automation Explorer (MAX), which will write this information to the Configuration Store. The average user doesn't interact with the Configuration Store directly but only through installers and higher-level configuration utilities.

Accessing Advanced Features

If you want to take advantage of the advanced features of LXI Class A and B instruments, such as software synchronization over the LAN, you also can work with a special API called IviLxiSync, which comes with each specific driver from each vendor. In IVI-C, it consists of a few more functions in the driver DLL. In IVI-COM, it is represented as yet another interface that COM-aware applications can take advantage of.

With IviLxiSync, you can configure an instrument to participate in IEEE 1588 time synchronization through a Web page and have the data automatically timestamped, or you also can set up LAN and Wired Trigger Bus triggers through normal SCPI commands. The purpose of the IviLxiSync API is to make that job easier. However, because each vendor supplies its own IviLxiSync API with its instrument drivers, you have to use a different library for each instrument.

How users approach LXI instrument drivers varies widely. Some are very happy to have prewritten drop-in drivers they can use right away for system development without worrying how they are implemented. Other users want to look inside to see how the driver is implemented and be able to debug and optimize the driver to meet their needs.

As a result, the availability of source code in a language they're familiar with for their instrument drivers can be important. Some users feel that drivers without source code can be problematic--they must rely on the driver vendor for explanations, bug fixes, or updates.

Sometimes instrument vendors contract driver work to third parties, making it even more difficult to get good support. On the other hand, drivers that ship with source code native to their development environment are easily understandable by end users.

For instance, engineers familiar with C can dig into IVI-C drivers. NI's LabWindows/CVI is a popular tool for C driver development. LabVIEW is another application development environment that enables end users to work with driver source code directly.

The Final Step: Discovery

With the instruments now communicating with the central controller, how do you find out what instruments actually are connected and what their network addresses are? This is where you run discovery tools, such as the Agilent Connection Expert (ACE) and NI's MAX. These tools search a network to discover all available LXI devices and make it easy to identify the instruments and view their Web pages. ACE is included with the Agilent 10 Libraries Suite, and MAX accompanies NI's development environments and driver software (FIGURE 2).