Using GPIB Instruments to Test Communication Systems

By John Porcello

Coming up with a communication standard that controls and collects data for a wide variety of equipment types is difficult. This type of instrument controls messages and output data from a logic analyzer is quite different from a spectrum analyzer, digital storage oscilloscope, signal generator, and others.

The general-purpose interface bus (GPIB) is a parallel bus used by computers to control and communicate with many types of test and measurement equipment. Originally designed by Hewlett Packard in the mid-1960s, it was called the HP Interface Bus (HPIB). This HPIB interface was very useful and became IEEE Standard 488 in 1975. The original standard was focused primarily on physical and electrical specifications and less on the actual computer and instrument communication protocol issues. The lack of a standardized protocol between instruments meant that early GPIB test configurations required a significant amount of software development time to design and implement. Designing GPIB test configurations was also limited by the selection of test equipment that had GPIB capability. If the only test equipment capable of performing the measurement you needed didn't have GPIB capability, you were out of luck. The 488 standard was later revised in 1987, with ANSI/IEEE 488.1-1987, focused on physical and electrical issues, and ANSI/IEEE 488.2-1987, focused on the communication protocol issues. ANSI/IEEE 488.2 was later revised in 1992.

Coming up with a communication standard that controls and collects data for a wide variety of equipment types is difficult. This type of instrument controls messages and output data from a logic analyzer, and is quite different from a spectrum analyzer, digital storage oscilloscope, signal generator, and others. In 1990, several instrument manufacturers organized the Standard Commands for Programmable Instruments (SCPI) Consortium and developed the SCPI specification. The specification is based on the SCPI instrument model and provides a much higher degree of commonality for instrument programming commands between different types of test equipment.

GPIB design considerations
Until recently, the task of putting together a GPIB test configuration has been a tedious one. This task usually required a long lead time to learn specific instrument commands, write any device drivers needed for the instruments or the hardware platform, and then integrate all the software to get a fully-functional test system. Committing this amount of engineering time for automated instrument measurements and control was rarely economical outside of large production runs that needed extensive testing. Typically, the engineer would manually operate the test equipment or train a technician to perform measurements and log test data manually. The capabilities of today's test software, with their large GPIB instrument libraries combined with the proliferation of GPIB test equipment, can allow the engineer to design and implement GPIB setups in a fraction of the usual time. This allows automation and execution of previously manually performed tests to occur in far less time and over the entire range of the product life cycle, such as design validation, manufacturing, and troubleshooting. The new test software suites for controlling GPIB instruments, combined with other technologies, allow testing in ways that were not previously possible. The overall effect is to shorten the time-to-market by reducing test times, as well as reducing labor costs associated with test and measurement.

An advanced GPIB test configuration is shown in Figure 1 . Most GPIB test configurations have one computer equipped with a single GPIB card controller that is designated as the active GPIB controller. There may be more than one controller card on each GPIB bus, but only one GPIB controller at a time may be the active controller for the connection of GPIB devices. A computer may control more than one GPIB bus by using more than one controller card, referred to as a multiboard system ( Figure 1 ). Instruments may be connected in a star or series configuration. The data rate over the GPIB bus (1 Mbps maximum) is substantially influenced by the specific instruments used on the bus, the physical cable lengths between instruments, and the number of devices powered on the bus. Although the GPIB bus is designed for a maximum of fifteen devices and a total of 20-m cable length on each bus, GPIB bus extenders are available to handle more than fifteen devices and longer cable lengths. The penalty for the increased devices and/or increased cable lengths is a reduction in the maximum data rate allowed over the bus. The instruments connected to the GPIB bus are configured (at the instrument) as talkers, listeners, or both, depending on the function of the particular instrument. Of the twenty-four lines that make up the GPIB bus, eight lines are used for data, eight more are grounded lines, five lines handle interface control, and three lines perform handshaking. The use of three-wire handshaking makes communication over the GPIB bus very reliable. However, even with a maximum data rate over the bus of 1 Mbps, actual data transfer over a GPIB bus is only as fast as the slowest listener.

Selecting GPIB test instruments
Designing a GPIB test setup is generally a superset of designing the same manually-operated test setup. That is, the design begins with assessing the technical performance of the equipment used to make measurements and acquire data. The selected GPIB test instruments must have the performance capabilities to meet the test requirements. Since GPIB capable instruments vary widely in instrument type, this may include a broad range of technical performance criteria and will vary depending on the specific test or tests to be conducted. In design validation and production testing, for example, the test equipment should have measurement performance that exceeds the performance characteristics of the system under test (SUT). The performance margin (difference) between test setup and SUT then insures accurate characterization of the SUT. In other situations, such as system troubleshooting, there may only be some measured characteristics or system anomalies. In these cases, it is the known performance of the test equipment that must be examined to identify limitations of measurement data and isolate a particular problem. In either case, the performance of the test equipment is the first consideration in designing a test configuration.

Test equipment performance, in this sense, also includes the GPIB performance of the test equipment. It is true that the GPIB bus will, in some configurations, support up to 1-Mbps data transfer. The new high-speed GPIB (HS488) will support even faster data rates up to several Mbps. However, the actual data rate over the bus is usually limited by the instruments and the measurements made by them. A fast GPIB bus is no guarantee that the instrument can make a measurement and put the data onto the bus at that speed. GPIB test instruments require some finite amount of processing time to turn digital information into an electrical stimulus and turn an electrical measurement back into digital data. This processing time is a function of the speed and capabilities of the instrument. This processing time can be significantly increased by any calculations that must be performed by the instrument prior to transmitting measured data, such as calculating the fast fourier transform (FFT) of an acquired waveform. For most designs, depending on the instrument and measurement, this usually leaves one or two instruments, with a limited data throughput that ranges from hundreds of Hz to a few hundred kHz.

Where measurement times and throughput considerations have a substantial impact on the design, the GPIB instrument's performance specification requires careful review and sometimes even technical support from the instrument manufacturer. The amount of processing time may be characterized using GPIB diagnostic software or a GPIB line analyzer. In most cases, simple GPIB diagnostic software (usually available with the controller card) will quantify the processing times and identify throughput bottlenecks in the test configuration. An example of this is National Instrument's (NI) GPIB SPY software, which logs and time-stamps GPIB activity on the bus. For GPIB commercial-off-the-shelf (COTS) equipment, a GPIB line analyzer is usually not required to pinpoint problems. In some cases, a reduction in instrument processing times and in the amount of data transferred from the instrument can be accomplished by having the test software command the GPIB test instrument (if the instrument has the capability) to transfer only the raw acquired data over the bus. The GPIB controller's computer processor (usually a much higher-performance processor) can then perform calculations on the data and thereby reduce the load on the bus. Commercially available test software, compatible with GPIB instruments, usually includes a variety of mathematical capabilities or additional software suites that allow the designer to customize the data processing once the computer has acquired data, using their own algorithms or external executables.

The discussion of the instrument's data acquisition time, processing time, and data transfer rate raises another concern on the GPIB test configuration. Although the GPIB command structure allows for sequencing bus activity through device service requests and wait commands, the nature of the GPIB bus restricts tasks over the bus to be performed one at a time. Therefore, the longer the GPIB bus is busy from instrument or device lag, the less time is available to issue new commands or acquire additional data. This can impose some unnecessary restrictions in design, particularly when performance criteria requires precision timing or transferring large amounts of data from instruments. Where precision timing is required, it is best to use a GPIB-compatible device as an external trigger and, thus, externally trigger all test equipment in the configuration that requires a precise timing signal. Where large data transfer or instrument lag is a problem, more than one GPIB controller card can be used to control another GPIB bus. A multiboard system allows the designer to operate another GPIB instrument or an entire test configuration on a separate bus, simultaneously, and thereby increase throughput. The ideal GPIB test configuration would be physically connected so that all GPIB devices are powered on, all GPIB cable lengths are as short as possible, and all GPIB devices are spaced equally on the order of one device every meter of cable length.

Choosing a GPIB controller card
Once the GPIB test instruments that will support the test requirements have been selected, the designer can focus on choosing the proper GPIB controller card and GPIB test software that will support testing. The controller card must be compatible with the computer's hardware platform and OS. Figure 2 shows a block diagram of compatibility issues between the GPIB controller card, computer hardware platform, computer OS, and GPIB test software. The GPIB controller card must be compatible with the computer's physical hardware and its OS. GPIB controller cards are available that will connect to a variety of computer hardware interfaces, such as PCI, PCMCIA, EISA, serial and parallel ports, Ethernet, VXI, and several other types of hardware interfaces. The majority of GPIB controller cards are compatible with Windows 3.x/95/NT. Many cards are also compatible with several flavors of Unix, like HP-UX and Solaris, as well as a few other OSes. Each of these GPIB controller cards requires a set of device drivers from the card manufacturer that allow software running on the computer to issue GPIB commands, acquire data from the GPIB test setup, and control instruments. These device drivers must also be compatible with the computer OS and hardware platform. Finally, the device drivers for a specific GPIB controller card must also be compatible with the GPIB test software selected. The compatibility between device drivers and test software is an important consideration. NI offers a large selection of GPIB controller cards, based on its (industry standard) NI-488.2 device drivers. These drivers are supported for a wide variety of computer platforms, hardware interfaces, and OSes.

The selection of the controller card should allow us to not only configure our current GPIB test configuration, but anticipate future requirements or applications. Will the GPIB setup be used remotely or in a multiboard system? Designing a remotely-operated GPIB test setup has special considerations from a GPIB setup in which all of the components are local. Mulitboard systems may also have unique considerations. Multiboard systems, for example, are effective at controlling more than one GPIB test configuration, provided the computer and the hardware interface to the GPIB controller card can support high-speed transfer. Because of their high bus speeds, GPIB controller cards that interface to the computer through PCI or PCMCIA will do a good job of supporting the load of a multiboard system. Other GPIB interfaces, such as a serial or parallel port, operate at a much slower throughput and can bottleneck a test configuration. A good rule of thumb is to select a controller card that meets all the compatibility issues in Figure 2 , including compatibility with the GPIB test software, and uses the fastest computer hardware interface available.

Choosing GPIB test software
Our goal here is to select GPIB COTS test software that's compatible with the instruments that will be used in the test configuration, the GPIB controller card, the OS, and the hardware platform. The GPIB test software should meet these requirements and have instrument drivers for each of the instruments in our test configuration. By using instrument drivers that come with the test software, we eliminate the necessity of writing instrument-specific code for each individual GPIB test setup - the advantage of which cannot be overstated. Today's sophisticated automatic test equipment (ATE) can have many instrument-specific commands for configuration, operation mode, status, control, and data acquisition. For advanced communication test setups, this can literally add up to a few hundred instrument-specific commands. Today's test software not only comes with large instrument libraries, but also capabilities for advanced analysis, signal processing, and data acquisition (non-GPIB) to support various types of communication testing.

Two noteworthy GPIB test software packages are HP's visual engineering environment (HPVEE) and NI's LAB Windows/CVI (C for virtual instrumentation). Both software packages contain large instrument libraries, are usable with several controller cards, and are supportable over a broad range of OSes and hardware platforms.

Both software packages can run simultaneously on a multiboard system. This allows each package to control a separate instrument in the same test configuration via a separate GPIB controller card and GPIB bus. For some designs, this offers significant advantages in rapid design and implementation of GPIB test configurations, as well as higher performance. First, this effectively increases the number of off-the-shelf instrument drivers by combining the instrument libraries from both software packages. Secondly, the additional bus or buses provide a significant performance advantage, since data transfer from the instruments to the computer can be split up over more than one bus. This type of multiboard system imposes a load on the computer OS and hardware to operate the controller cards and multitask between applications. This is where we want the load - not bottlenecked at the GPIB controller card or waiting to get data or commands on the GPIB bus. In these types of configurations, communication between software packages (processes) can be accomplished through dynamic data exchange (DDE) in a Windows environment with HPVEE as the DDE client and LAB Windows/CVI as the DDE server. For Unix systems, a similar form of interprocess communication may be used to perform this task.

Once the software package is selected, the task is now concentrated on writing software to perform the desired test(s), and recording, analyzing, and displaying test data. There are various means available to communicate with other applications on a system.

A GPIB design example
Figure 3 shows the graphical user interface (GUI) for this type of multiboard GPIB system using both HPVEE and LAB Windows/CVI. Based on the test requirements and available test equipment, we needed to rapidly implement and control two types of test equipment. HPVEE offered an off-the-shelf instrument driver for the HP 5372A time interval analyzer (TIA), and LAB Windows/CVI offered an off-the-shelf instrument driver for the Tektronix 2440 digitizing oscilloscope. A laptop computer was equipped with two PCMCIA-GPIB controller cards; GPIB0 (bus #1) controlled the scope, and GPIB1 (bus #2) controlled the TIA. Client HPVEE and LAB Windows/CVI server programs were written that used DDE to send the scope trace from the server to the client. The scope trace (1,024 data points) was then monitored in (near) real-time while the TIA was controlled via a separate bus. The test setup was quickly configured using off-the-shelf instrument drivers. Note that we could have used the server to perform additional processing and analysis on the scope data and to reduce processing load on the client, as well as distribute this processing across more than one computer.

Remote test configurations
Testing communication equipment can require that a GPIB configuration test data remotely and/or control the GPIB test configuration. The location may be mobile or otherwise beyond the distance capabilities of a GPIB bus extender or short-range wireless connection. In these remote applications, where a phone line or radio link is the only data link available, a GPIB to the serial port interface can provide a relatively inexpensive solution. Using a GPIB to the serial port interface as the GPIB controller is referred to as an S-Mode configuration. Remote designs of this type first establish modem communications and then initiate GPIB operation. Establishing modem communications and using serial data transfer imposes a reduced data-transfer rate and some additional design and programming work with the test software.

John Porcello is currently a senior systems engineer for Veda Inc. and designs, analyzes, and tests both hardware and software. He received his BS in Engineering Science from Montana College of Mineral Science and Technology, and an MSEE from Northeastern University.

---