IEEE 488: not dead yet?

Like the character in the famous Monty Python sketch, IEEE 488 is not dead yet. The decades-old standard's longevity is in question, however, and you probably have good reason to care about its fight for life. Whether you design test-and-measurement instruments, develop or implement systems that incorporate test-and-measurement products that others design, or simply use such products in your lab or test facility, the methods that instruments use to communicate with each other and with host computers matter a lot. The communications medium's physical implementation, protocol, and instrument-specific command sets strongly influence instruments' and systems' speed and cost and the time EEs must spend programming and debugging test applications.

In 1977, the IEEE adopted the bus structure and communication protocol that it named IEEE 488. Some others call it GPIB (general-purpose instrumentation bus). The bus's original name was HPIB (Hewlett-Packard instrumentation bus). HP, which, in 1999, spun off its electronic test-and-measurement business as Agilent Technologies, was the largest manufacturer of such equipment, a market position that Agilent still enjoys. Even before the early 1980s ushered in the widespread availability of PCs, large numbers of minicomputers (remember them?) were in use controlling instruments and processing the data they generated.

Until the advent of the HPIB, no standardized methods existed for interfacing instruments with computers. It's only a slight exaggeration to say that no two instruments interfaced in the same way. The RS-232 serial-communication standard and the Centronics parallel-printer interface did a decent job of standardizing the computer side of the interface and even motivated some standardization on the instrument side. (RS-232 ports became popular on slower instruments.) Still, because it was rugged and relatively speedy, was designed for instrument interfacing, and was backed by HP's clout, IEEE 488 remained for more than two decades the industry's primary standard for enabling instruments and computers to talk with one another.

Even so, IEEE 488's early era was no bed of roses. Although the standard did a good job of defining the communications hardware, it initially gave short shrift to interfacing's software aspects. More than a decade elapsed before the evolution of the necessary software standards, particularly SCPI (standard commands for programmable instruments). It took still longer to develop standard instrument drivers, whose existence relieved test-system designers of a great deal of application-specific programming.

The idea that the electronics industry includes a segment that marks its evolution in decades rather than months must seem bizarre—even unthinkable—to younger EEs whose experience stretches back only as far as the go-go days of the late 1990s. However, this seemingly torpid pace is keeping IEEE 488 alive, even if not in the most robust health, and will continue to do so for years to come.

To many observers, though, propelled by ubiquitous computer-interconnect standards, IEEE 488 appears to have entered the end game. It may not go quietly—powerful forces will keep it alive for years, but many in the industry see its demise as inevitable. A decade from now, on test floors and maybe even in some design labs, you'll still see instruments with IEEE 488 connectors and cables, but you'll probably have to look around for a while to find them.

The main reason that IEEE 488 will survive for so long is that, for years to come, many instruments with IEEE 488 ports will continue to perform useful work for their owners. Instruments such as benchtop DMMs measure quantities such as volts, amperes, and ohms, which will not change in 20 years—or ever. Sure, newer DMMs will be faster, more accurate, and less expensive and will measure lower currents and higher resistances, but if you own a DMM that meets your needs and still reliably meets its specifications, you require a strong incentive to replace it. On the other hand, some types of instruments, such as oscilloscopes, change more rapidly. Signal speeds continue to increase, making wider bandwidth scopes necessary. Scopes that offer communication ports other than IEEE 488 are becoming increasingly common. The result of the need to intermix old and new instruments will be increasing numbers of instrumentation setups that also intermix communication protocols (Figure 1).

The current and most likely future leader in replacing IEEE 488 is Ethernet. USB will also play a major role; indeed, several of Agilent's latest instruments support USB 2.0 and, because USB 2.0 is backward-compatible, they support USB 1.1 as well. Another external serial bus, FireWire, also known as IEEE 1394, no longer appears to figure significantly in the future of instrument interfacing, even though it is technically superior to USB, including USB 2.0. The reasons are primarily political.

Thanks to a more efficient protocol and in spite of a raw bit rate 20% lower than USB 2.0's, FireWire—even in its initial implementation—is faster than USB 2.0. Subsequent versions of FireWire will be still faster. Moreover, unlike the host-centric USB, FireWire, with its peer-to-peer topology, seems tailor-made for test-and-measurement systems that include both a host computer and instruments such as modern oscilloscopes and logic analyzers, which contain their own computers. (By enabling several computers to share control of the bus, the new OTG (On The Go) extension of USB 2.0 should at least partially overcome FireWire's advantages in applications that embody multiple computers that can act as hosts.) But, whereas manufacturers need not pay royalties to use USB in their products, using the patented FireWire technology requires royalty payments. The royalty situation together with the influence of a few large companies that back it has enabled USB to leap ahead of FireWire in test-and-measurement applications.

The most obvious reasons for turning to computer-standard interfaces in place of IEEE 488 for instruments are cost, size, cable length of instrument networks, and increasing difficulty of installing specialized peripheral controllers in newer PCs. Here, "PCs" refer not just to laptops, but also to the new breed of small desktop machines in "sealed" enclosures. Greater speed, an apparent advantage of the newer interfaces, is often an illusion, however (see sidebar, "Understanding instrument I/O: performance and protocols"). In fact, in typical instrumentation applications, which involve short messages, IEEE 488, rather like the tortoise that won the race with the hare, can prove faster than protocols that are nominally hundreds of times as fast. Besides speed, the most important reasons for staying with IEEE 488 are the existence of such a large infrastructure supporting it, instruments' long service lives, and the physical ruggedness of IEEE 488 connectors and cables.

Industry groups and software vendors are hard at work on the infrastructure problem. They aim to make customers' libraries of control routines work without modification through the PC's USB or Ethernet port and the corresponding ports of instruments that lack IEEE 488 interfaces. Moreover, several companies now offer external adapters, which let PCs that provide only USB or Ethernet ports and lack IEEE 488 ports control instruments whose only interface is an IEEE 488 port. The compatibility that the software libraries and port adapters make possible is exactly what you need to economically and quickly build instrumentation systems that mix communication protocols.

Using an instrument as a Web server is one aspect of 21st-century instrument interfacing that nobody could have envisioned when HPIB's developers invented the bus. Web-server technology is particularly well-suited to instruments that connect to Ethernet networks and that use TCP/IP (Transfer Control Protocol/Internet Protocol).

In one sense, some proponents of Web-based test and measurement have made more of this technology than is justified. It's true that Web-server technology has become so compact and inexpensive that individual sensors costing no more than a few hundred dollars each can transmit Web pages that users can view via the browser software of any Web-enabled PC. Still, the approach quickly becomes unmanageable in applications that involve more than a few sensors.

Applications involving hundreds and even thousands of sensors are common. To aggregate the multiple device outputs into a Web page that portrays the data in a form that users can understand, these applications need software that can't reside within individual sensors. If more than a few users are to view the data, the best arrangement is to let the computer that controls the test setup aggregate the data and serve the Web page. Thus, though inexpensive, servers embedded in the sensors still constitute overkill.

For test instruments, an advantage of an Ethernet connection over a USB or IEEE 488 connection is Ethernet's much greater allowable cable length. Ethernet LANs—even using gigabit-per-second Ethernet technology—can span thousands of feet. USB and IEEE 488 are limited to tens of feet. Although the shorter cables are usually adequate for linking units mounted in several adjacent equipment racks, the IEEE 488 and USB approaches can fail if the computer that controls the test setup is not adjacent to the instrument racks.

Engineers have often solved this problem by assigning the instrument-control functions to a computer near the test equipment and using Ethernet to link this control computer to the more distant host, which might perform data reduction and provide the user interface. Now, however, you can often eliminate the separate control computer. To do without it, the instruments must include their own Ethernet interfaces, or the system must include an adapter that communicates with the host via Ethernet and with the instruments via IEEE 488 or USB. This adapter can be small and is usually less expensive than a PC.

Bear in mind, though, that if your test equipment generates a lot of network traffic by sending large amounts of data to the host, it may be inappropriate to share the Ethernet LAN with other users. Despite the seemingly huge bandwidth of 100-Mbps and 1-Gbps Ethernet LANs, you may find that your test setup must have a control computer close to the instruments, and, to keep traffic on the shared network manageable, the control computer must reduce the data before transmitting it to the host.

When you use USB as your instrumentation bus, a feature that at first appears to be a USB advantage can turn into a complication if you configure your system differently from the way USB's system architects envisioned. In the absence of not yet widely available OTG capabilities, USB is a host-centric bus. If one of your instruments is built on a PC, as are today's highest performance digital oscilloscopes and logic analyzers, the instrument can act as the host PC for your computer-controlled test setup. But, if you want to use a separate computer as the host, the host can't use USB to communicate with the computer-based instrument, because such an instrument's USB port is the wrong type. The developers of USB, including USB 2.0, intended it to have one computer per bus, and that computer had to be the host.

To make the PC-based instrument act as a USB peripheral and not a host, you need hardware that isn't commonly available—an I/O adapter card that contains a USB-peripheral connector and peripheral controller—and you need to modify the BIOS firmware on the computer-based instrument's PC motherboard. For many PC-based instruments, a more convenient approach exists, however. If the instrument's PC motherboard contains an Ethernet port, as many do, you can use that port for communication with the host and you can use the PC-based instrument as the test setup's control computer. You can't, however, use this elegant approach if the manufacturer designed the PC-based instrument's embedded software to make the instrument a closed system, which performs only the primary instrument functions. One vendor designed its older PC-based scopes in exactly this way.

National Instruments' business started with IEEE 488 interfaces and grew to include what is probably the industry's widest array of data-acquisition and modular-instrumentation hardware as well as a broad assortment of data-acquisition and test-and-measurement software. LabView is the company's best-known software package and probably its best-known product. Nevertheless, despite all of the other businesses it has entered, NI continues to supply IEEE 488 interfaces and gives no indication that it will curtail its efforts in this area any time soon. In fact, it has just introduced an IEEE 488-interface IC, which it will use in its own hardware products and will resell to companies that continue to design IEEE 488 interfaces into test-and-measurement products. By combining IEEE 488 and PCI connectivity as well as IEEE 488 transceivers in one chip, the TNT5002 helps instrument manufacturers simplify instrument design (Picture). On a pc board, the chip occupies less room than do the traditional three or four chips, thus making instruments easier and less expensive to manufacture. The chip uses a 3.3V PCI core, supports both 3.3 and 5V signaling, and complies fully with revision 2.2 of the PCI local-bus specification. A development kit containing 24 chips costs $600.

Author Information

Senior Technical Editor Dan Strassberg has been providing EDN 's coverage of instruments that interface via IEEE 488 for almost 16 years. You can reach him at dstrassberg@edn.com.