Keysight Technologies conceived of LAN Extensions for Instrumentation (LXI) in 2005 as a way to enable test and measurement interfaces using web servers in conjunction with Ethernet. LXI is used extensively in connecting computers and electronic test equipment, particularly oscilloscopes.

Local Area Network (LAN)-enabled instruments can connect to a computer, using as a medium the user-friendly Ethernet protocol. This has been done for years, but the LXI innovation established a standardized behavior for any instrument when connecting over a LAN. The LAN can be wired or wireless. It is compatible with multiple protocols and web servers may be embedded in the individual instruments.

Numerous types of instrumentation can employ LXI to connect to devices – everything from power supplies to solar array simulators. Prominent among these instruments are oscilloscopes and spectrum analyzers.

Prior to the development of LXI, the General Purpose Interface Bus (GPIB) was the usual interface. After LXI emerged in 2005, this faster, more efficient and less costly alternative became the tool of choice for computer-to-instrument connectivity.

The trend is toward higher speeds. Currently, LXI instruments are available with Ethernet speeds of 100 Mb/sec and 1 Gb/sec. These limits will be exceeded in the near future. Because of backward compatibility, existing systems will never become obsolete.

Currently, all LXI enabled devices adhere to what is known as the LXI core. These devices connect in a uniform manner to any LAN, and the end products have in common:

• Open industry standards – LXI includes TCP/IP, Ethernet, Ipv4/Ipv6, web browsers and IVI drivers.
• High-speed Ethernet I/O, which provides backward compatibility and universal connectivity. Today’s computers invariably include Ethernet ports, and networking hardware is readily available.
• Internal web interface. The LXI standard mandates that instruments support W3C-compliant browsers.

Taking advantage of the web interface, the user can configure and operate instruments from an embedded web server GUI. Data can be collected and analyzed without additional programming. Instruments, confined to the LAN, can be operated remotely within the LAN or, connected to the Internet, they may be operated remotely throughout the world.

LXI devices universally contain an Interchangeable Virtual Instrument (IVI) driver, which provides a consistent programming interface. LXI software is comprehensive and reliable. However, the individual device manufacturers furnish proprietary software that is unique to each device. Through no fault of LXI, some aspects of this manufacturer-supplied, device-specific software are often found to be deficient. For this reason, and because LXI is an open standard, many users choose to create their own instrument-specific software. Linux and Mac command lines permit text programming compatible with a TCP connection.

Here’s an example, using the Telnet command line tool to connect to a Rigol DSA815 oscilloscope:

$ telnet 192.168.1.126 5555
Trying 192.168.1.126…
Connected to 192.168.1.126.
Escape character is ‘^]’.
*IDN?
Rigol Technologies,DSA815,DSA8A154402661,00.01.07.00.01

Here is the code for a frequency response plot from 100 kHz to 10 MHz using the internal tracking generator:

# enable tracking generator output
:OUTP 1
# average 1000 measurements
:TRACE:AVER:COUN 1000
# frequency range from 0 to 10 MHz
:SENSe:FREQ:START 10000
:SENSe:FREQ:STOP 10000000

Most problems are easily resolved, but it is possible to have a hardware difficulty that requires extensive component substitution. That can get expensive, but the good news is that most problems are either in the software or they are procedural.

One common fault is that on the front panel of an LXI device, the LAN status indicator reads FAULT. Possible causes are a faulty LAN cable or a faulty termination. Ohmmeter readings are not definitive because there may appear to be electrical continuity while the signal path is problematic. In a long cable run, media can be pinched due to over-tightened support hardware, causing an impedance mismatch. The answer is to replace the cable with a known good piece.

Check that the switch or router is ON.

The LAN status will read FAULT if the LXI device is trying to use the wrong IP address. If the Discovery Tool finds the LXI device but can’t access the web page, it is possible that the IP address does not match the subnet of the computer. The solution is to activate the LCI mechanism (LAN reset). This should align the LXI device IP address and the computer subnet. If that does not work, an alternate solution may be to configure the computer to use DHCP or to use a static IP address and subnet mask matching the subnet of the LXI device.

Test and measurement instruments that comply with the LXI specification include an internal web server that responds to an http request directed to its IP address. Then, without drivers, the instrument is prepared to respond to Standard Commands for Programmable Instruments (SCPI).

SCPI facilitates communication over LXI by providing syntax, command structure, and data transfer protocol. As in all programming, the user must be aware of conventions that govern the use of the language. For example, in writing a command, the first three letters are written in uppercase and they define the action. The lowercase letters are optional and may be included for clarity. Two common SCPI commands are MEAsure and CONfigure.

Generic commands, independent of any specific instrument, can be issued, and this makes switch-and-play possible without code revision.

Specific media are not required. SCPI works with RS-232, Ethernet, LXI, USB, PXI, VXIbus and others.

SCPI is comprised of two fundamental command types: common commands and instrument control commands. Common commands do not relate to a specific instrument. Examples are RESET and ESR? which queries the status of the event register. Instrument control commands are discussed in detail along with common commands at na.Support.keysight.com.

One of the weaknesses of GPIB, in contrast to IVI, was that commands were not standardized. There were many vendors, and they tended to determine commands and actions without regard to differing models. Engineers could not know what commands would do in programming the many extant instruments.

Standard Commands for Programmable Instrumentation (SCPI) resolved these uncertainties. Proposed by Hewlett-Packard in 1990 and managed by the SCPI Consortium, it evolved under IVI Foundation management and succeeded in defining a signal-oriented language that instruments could interpret without latency.

SCPI has gained increasingly wide currency thanks to its outstanding interoperability and user-friendly nature. Without the need of drivers, the ASCII commands are performed by the instruments, minimizing the opportunity for error. That being said, we must recognize the SCPI cannot compete with IVI drivers in terms of speed, so it is a question of setting priorities in a proposed system.

Instruments receive SCPI commands in the form of a Set operation or a Query operation. All queries end with a question mark. A set will command an instrument to perform a specific operation such as Power On or Power Off. A query will request data such as a voltage or current level. Some commands can be both set and query.

A common command configuration is a hierarchy or tree. Within a tree successive commands are separated by colons. A voltage or current measurement query is a hierarchical command and as such takes the form MEASure:VOLTage:DC? Or MEASure:CURRent: AC? If these commands are combined, they are separated by a semicolon. The actual command is the upper-case portion. The lower-case letters are for clarity and may be omitted.

Arguments consist of additional command text that clarifies the overall intent. They occur after the command, separated by a space.

IVIfoundation.org publishes on its website a PDF titled Standard Commands for Programmable Instruments. Volume 1 is Syntax and Style. This document states explicitly that by following a set of simple guidelines, a programmer can reduce the number of errors encountered when using SCPI instruments. Some guidelines are:

1.  Avoid sending default nodes. Default nodes are used within SCPI to allow the language to grow. Thus, older instruments will not have implemented the default node. A command is more likely to work with more instruments if the default nodes are omitted.
2. Avoid sending a numeric suffix of 1 in applications that only use the default capability. An instrument with multiple capabilities is required to interpret a header without the numeric suffix as if a numeric suffix of one had been used. Leaving off the numeric suffix means the same commands will work with an instrument that has multiple capabilities and an instrument that does not.
3. Be careful when sending coupled commands. If the coupled commands are contiguous in the same program message, the instrument is more likely to resolve any conflict between the current settings and the new settings.
4. Verify instrument settings when knowing their exact value is required. If the actual value of a setting is important, query the setting after programming it. An instrument is required to round parameters.
5. Send commands and queries in different program messages. The response from a query combined in a program message with commands that affect the queried value is not predictable.
6. Use the highest level commands possible for compatibility across instruments. Whenever feasible, use the MEASure, CONFigure, READ?, FETCh?, and INITiate commands. Use the lower level commands only when a special characteristic of an instrument must be manipulated.