Increasing Test System Compatibility and Productivity with IEEE 488.2

This document discusses the benefits of a complete IEEE 488.2 system and how IEEE 488.2 can create more compatible, reliable, and efficient test systems. All benefits and examples described in this document relate only to completely IEEE 488.2-compatible systems.

1. Introduction
2. IEEE 488.2 Controllers
3. IEEE 488.2 Instruments
4. Conclusion: The New Generation of GPIB
5. References

Introduction

In recent years, significant General Purpose Interface Bus (GPIB) standards such as IEEE 488.2 have defined the future of test instrumentation systems. The IEEE 488.2 standard meets the changing needs of automated test system developers by removing the limitations and ambiguities of the original IEEE 488 standard. With IEEE 488.2, you can design more efficient and reliable test systems.

The ANSI/IEEE Standard 488.1-1987, now called IEEE 488.1, simplified the interconnection of programmable instruments by clearly defining mechanical, electrical, and protocol specifications. For the first time, a standard cable could connect instruments from different manufacturers. While this standard improved the productivity of test engineers, years of implementation revealed a number of problems. Specifically, IEEE 488.1 did not account for data formats, status reporting, common configuration and device-specific commands, nor error handling. As a result, each manufacturer implemented these items differently. Integrating these different instruments presented a formidable task for the test system programmer.

The adoption of ANSI/IEEE Standard 488.2-1987 encouraged new growth and acceptance of the IEEE 488 bus or GPIB. By standardizing instrument and Controller interaction, IEEE 488.2 reduces test system development time and ensures reliable, efficient systems. IEEE 488.2 enhances and strengthens IEEE 488.1 by defining data formats, message handling protocols, status reporting, error handling, Controller requirements, and a common set of commands that all IEEE 488.2 instruments must respond to in a defined manner. Another benefit is that the IEEE 488.2 standard remains compatible with the original IEEE 488.1 standard. IEEE 488.2 devices accept a wide range of commands and data formats so that the system can include IEEE 488.1 devices, if necessary.

IEEE 488.2 Controllers

Although the IEEE 488.2 standard has a greater impact on instruments than on Controllers, several new requirements and optional improvements for Controllers make them a necessary component of new test systems. The IEEE 488.2 standard defines how Controllers send commands and data and also defines useful new functions. Adhering to the new IEEE 488.2 Controller requirements, instrument manufacturers now design more compatible and efficient instruments. For the test system developer, this compatibility translates into reduced development time and cost. The following sections discuss the IEEE 488.2 requirements and recommendations for Controllers.

Requirements for IEEE 488.2 Controllers
The IEEE 488.2 standard defines a number of Controller-specific requirements that include an exact set of IEEE 488.1 interface capabilities, bus control sequences, and bus protocols. An IEEE 488.2 Controller must be able to:

• Pulse the Interface Clear (IFC) signal line TRUE for greater than 100 µs
• Set the Remote Enable (REN) signal line either TRUE or FALSE
• Send any IEEE 488.1 interface message
• Send and detect the IEEE 488.1 END message (End or Identify (EOI) signal line asserted)
• Send or receive the IEEE 488.2 codes, data formats, protocols, and common commands
• Sense the state of the Service Request (SRQ) signal line
• Investigate each bit of an instrument status byte
• Detect and report the error condition of the Controller sending a byte while other instruments are in Acceptor Idle State (AIDS)
• Timeout on any I/O transaction

Recommendations for IEEE 488.2 Controllers
In addition to the new requirements, the IEEE 488.2 standard also lists three useful recommendations for Controllers:

• With bus line monitoring, you can monitor any of the IEEE 488 bus lines and report their status for diagnostic purposes. For example, a Controller can determine which devices are active, or listening, by monitoring the Not Data Accepted (NDAC) handshake line.
• With timeouts, you can vary the length of the timeout period and tailor the timeout values to the speeds of the instruments in a particular test system. You can thus increase throughput of application programs because they will respond more quickly to faster instruments.
• With SRQ handling, you can program an application to detect a FALSE to TRUE transition of the SRQ signal line so the program can branch to a service request handling routine that increases throughput.

Benefits of Using an IEEE 488.2 Controller
The IEEE 488.2 Controller requirements and recommendations benefit system developers by eliminating most of the problems they experienced with the IEEE 488.1 standard. The following sections discuss the benefits of using an IEEE 488.2 Controller.

IEEE 488.2 Control Sequences
The IEEE 488.2 control sequences make instruments and Controllers more compatible with each other by defining the exact states of the GPIB and the ordering of command messages for each of the defined operations. Because the IEEE 488.1 standard did not standardize control sequences, individual developers created their own. This often created compatibility problems. For example, the Attention line was sometimes asserted at the end of an operation, and commands were sometimes sent at the start or end of an operation to unaddress devices.

The IEEE 488.2 standard specifically defines common bus states and how devices should respond to standard messages. If an IEEE 488 instrument was designed for certain command sequences and/or bus conditions used by an IEEE 488 Controller from one vendor, the instrument might not work properly with a Controller from another vendor. With IEEE 488.2 control sequences, both Controller and Talker/Listener devices have a set of rules to follow to ensure complete compatibility among vendors. Table 1 shows the 15 required control sequences and four optional control sequences defined in the IEEE 488.2 standard for Controllers.



IEEE 488.2 Protocols
IEEE 488.2 protocols are high-level routines that reduce development time because they use a proven algorithm, combining a number of control sequences to execute the most common test system operations. IEEE 488.2 defines two required protocols and six optional protocols as shown in Table 2. The RESET protocol initializes the GPIB and clears all devices so that they are in a known state. The ALLSPOLL protocol serial polls each device and returns the status byte of each device. The PASSCTL and REQUESTCTL protocols pass control of the bus between different devices. The system-wide TESTSYS protocol instructs each device to run its own self-tests and report back to the Controller whether it has a problem or is ready for operation.

One of the most important protocols, FINDLSTN, uses the IEEE 488.2 Controller capability of monitoring bus lines to identify which devices are present on the bus. An application program might use FINDLSTN at the beginning of the test sequence to ensure proper system configuration and to create a valid list of active GPIB devices. The Controller implements the FINDLSTN protocol by issuing particular listen addresses, one at a time, and then monitoring the NDAC handshake line to determine if devices exist at those addresses. The result of the FINDLSTN protocol is a list of addresses for all the located devices. You can also use the bus line monitoring capability of the IEEE 488.2 Controller to detect and diagnose problems within a test system, such as detecting when control or data lines are stuck TRUE or FALSE or monitoring the state of the SRQ line.


Used in conjunction with FINDLSTN, the SETADD protocol dynamically assigns device addresses to the located devices. This ensures that there are no addressing conflicts and that the addresses expected by an application program match those of the actual instruments in the system.

Another important protocol, FINDRQS, provides an efficient mechanism for locating and polling devices that request service. It uses the IEEE 488.2 Controller capability of sensing the FALSE to TRUE transition of the SRQ line. An application program may prioritize the device list so that the more critical devices receive service first. If the SRQ line is asserted, calling FINDRQS immediately results in increased program efficiency and throughput.

IEEE 488.2 Termination Character
With the IEEE 488.2 standard, data transfers must terminate with the new line character and the EOI signal line asserted. The standard defines the new line character as the ASCII byte 0A. An IEEE 488.2 Controller must terminate a data transfer upon receipt of the new line character plus EOI. Before the IEEE 488.2 standard, instrument manufacturers chose their own termination character or did not use a termination character at all. Because the standard precisely defines the termination character, an IEEE 488.2 Controller can increase program throughput by automatically detecting the character in hardware instead of relying on the software driver, which adds software overhead.

IEEE 488.2 Instruments

The substantial impact of the IEEE 488.2 standard might require changes in the firmware and possibly the hardware of instruments. Although these changes require a development investment from the instrument manufacturer, the system developer gains stable, reliable firmware and instruments that are easier to program. Because IEEE 488.2 instruments use standard message exchange protocols and data formats, their responses to queries are well-defined.

The IEEE 488.2 message exchange protocol is also the foundation for the Standard Commands for Programmable Instruments (SCPI) standard that makes test system programming even easier. SCPI defines a standard command set for instrument-specific operations used by all types of instruments, regardless of manufacturer. Developers can use a combination of IEEE 488.2 common commands and queries and SCPI to program all SCPI-compatible instruments.

Background
Before the IEEE 488.2 standard, instrument interface capabilities could range from listen-only and talk-only to System Controller. As a result, developers could not simply replace instruments based on measurement functionality or performance, even if the instruments were from the same manufacturer. They had to consider the interface capabilities of the instrument as well. For example, one function generator might have had both Talker and Listener capabilities while another had Listener-only capability.

Another problem was that programming commands, data codes and formats, and status reporting were not standardized. Programming commands for instruments with similar functionality were not the same, even if the instruments were from the same manufacturer. The system developer often had to learn a different command set for each instrument, and exchanging instruments in a test system required a large number of program changes.

Other common instrument problems included internal device functions that reset when the System Controller asserts IFC or the Controller uses multiple I/O operations, or a data transfer aborts due to no addressing, unaddressing, or readdressing of instruments on the GPIB. Often, the instrument firmware accepted a certain combination of these messages, but they were not standardized. The system developer had to treat each instrument separately and on a case-by-case basis.

All of these problems made the use of IEEE 488.1 more difficult, resulting in lengthy and costly development of test systems. The following sections describe how the IEEE 488.2 standard solved many of the problems encountered with the IEEE 488.1 standard.

Benefits of Using IEEE 488.2 Instruments
The IEEE 488.2 requirements for instruments reduce programming development time, increase system compatibility and reliability, and ease programming hassles when interchanging instruments.

IEEE 488.2 Interface Capabilities
The IEEE 488.2 standard defines a minimum set of IEEE 488.1 interface capabilities that an instrument must have. All devices must send and receive data, request service, and respond to a device clear message.

IEEE 488.2 Message Exchange Protocol
The IEEE 488.2 standard precisely defines the format of instrument commands and the format and coding of instrument responses. An instrument may not send responses until commanded to do so. When an instrument receives a new command, it clears its output queue and processes the new command. The standard also incorporates error and exception handling procedures in cases where an instrument receives multiple commands, a non-terminated command, or an interruption in commands.

The message exchange protocol defines forgiving listening and precise talking. As an example, a function generator may output frequencies of 1, 5, 10, 50, and 100 Hz. This function generator must be able to accept commands with data formats such as 54.576, 5.0E+1, +50, 50, or +0.523E+2. When the instrument receives a value of greater precision than it expects, such as 54.576, it rounds the number to its acceptable precision (50). The function generator is a forgiving Listener in this case. If you query the instrument for its frequency value, however, its response must have a precise format. In this way the instrument is a precise Talker.

With IEEE 488.2, the structure of instrument programming commands and queries consists of program headers, separators, and terminators. All of the data codes and formats defined in the IEEE 488.2 standard also apply to commands and queries. A command mnemonic can use only uppercase and lowercase alphabet characters, the underscore “_” character, and digits 1 through 9. In addition, the IEEE 488.2 standard sets the maximum number of characters used for the command mnemonic to 12. The preferred length is four characters.

You can send queries to instruments to receive response messages. The syntax of a query is identical to that of a command except a question mark “?” always follows a query. Response messages from the instrument follow the same rules as the programming commands and queries. The New Line character along with the EOI line being asserted (END message) serves as the data termination mechanism.

IEEE 488.2 Data Coding and Formats
The IEEE 488.2 standard defines the coding and formats for all numerical data and character strings–for example, 7-bit ASCII codes for alphanumerics, 8-bit binary codes for integers, and IEEE Standard 754 codes for binary floating-point numbers. IEEE 488.2 also defines the format for decimal, hexadecimal, and octal numbers, as well as formats to send blocks of 8-bit bytes and ASCII character strings.

IEEE 488.2 Common Commands and Queries
All GPIB instruments must perform particular operations to communicate and report status. Since these operations are common to all instruments, IEEE 488.2 defines the programming commands used to execute these operations and the queries used to receive common status information. The functions of these commands and queries fall into the following categories:

• Automatic address configuration (Auto Configure)
• Instrument-specific information and parameters (System Data)
• Internal instrument operations (Internal Operations)
• Operation synchronization (Synchronization)
• Macro definitions (Macro)
• Parallel poll responses (Parallel Poll)
• Device trigger and responses (Trigger)
• Passing control (Controller)
• Settings for the state of the instrument (Stored Settings)

Table 3 displays each of the common commands and queries along with a brief functional description, the designated group, and the compliance requirements.



IEEE 488.2 Status Reporting
The IEEE 488.2 standard requires a standard scheme for instrument status reporting. With this scheme, the Controller knows exactly how to obtain status information from every instrument in the system. IEEE 488.2 builds upon and extends the IEEE 488.1 status byte by defining two additional bits. The RQS bit remains as defined in IEEE 488.1, but the IEEE 488.2 standard adds the Event Status Bit (ESB) and the Message Available Bit (MAV) as shown in Figure 1.

The RQS bit indicates that the device has requested service by asserting the SRQ line. (The developer can enable an instrument to assert the SRQ line by setting the corresponding bits in the Service Request Enable Register.) The ESB indicates that one of the standard events defined in the Standard Event Status Register has occurred. The system developer defines which standard events will set the ESB by setting the corresponding bits in the Standard Event Status Enable Register. The MAV bit indicates whether or not a message is available in the output queue of the instrument. Instrument manufacturers can use the undefined bits to fit their needs. Under the IEEE 488.2 standard, the RQS performs a dual role. This bit also serves as the Master Summary Status (MSS) bit. The MSS bit indicates whether or not there is at least one reason for the instrument to request service. The status byte query (*STB?) is the only method for retrieving the status of this bit. A serial poll cannot retrieve this status information because the MSS bit is not part of the IEEE 488.1 status byte.

The original IEEE 488 standard simplified the interconnection of programmable instruments by defining the electrical and mechanical specifications. As a result, it became the leading instrumentation standard. But IEEE 488 systems were difficult to program and integrate because the standard did not precisely define command and data formats, status reporting, common commands, Controller requirements, and message exchange protocols. The IEEE 488.2 standard resolves these issues and removes the ambiguities found in GPIB systems. The sooner the test and measurement industry adheres to IEEE 488.2, the sooner test system developers can spend more time developing and running test programs and less time debugging their system.

IEEE 488.2 Chips
National Instruments provides IEEE 488.2 capability to developers of programmable instruments through its application-specific integrated circuits (ASICs). In 1990, National Instruments announced the NAT4882®, the industry’s first IEEE 488.2 Talker, Listener, and Controller chip. In addition to complete software compatibility with the older NEC µPD7210 and Texas Instruments TMS 9914A chips, the NAT4882 has additional registers that implement the required and recommended elements of the IEEE 488.2 standard, including the preferred Service Request implementation and preventing data or command transmission when no Listeners are present. The NAT4882 also adds special last-byte handling circuitry for DMA transfers, which reduces the amount of software overhead and increases data throughput.

Because the NAT4882 contains a complete NEC µPD7210 and TI TMS 9914A register set, developers using either of these chips can port existing code directly to the NAT4882, thereby significantly reducing software development time. Further, with just a few modifications, the instrument developer can implement all the improved features of the IEEE 488.2 standard.

In 1993, National Instruments introduced the NAT7210™ and NAT9914™ Talker, Listener, and Controller chips. The NAT7210 is a pin and register-compatible replacement for the NEC µPD7210. The NAT9914 is a pin and register-compatible replacement for the TI TMS 9914A. Both chips can implement IEEE 488.2 compatibility through software, but retain the 40-pin dual inline package form factor and programming conventions. Thus, instrument manufacturers can upgrade their existing systems to IEEE 488.2 with only minor software changes.

Also, in 1993, National Instruments announced the TNT4882™ IEEE 488.2 Talker/Listener chip for developers of programmable instruments. The TNT4882 includes the circuitry of the NAT4882 ASIC, circuitry to provide maximum performance, and GPIB transceiver circuitry into a single chip. The TNT4882 also includes circuitry to implement HS488, a high-speed data transfer protocol that can attain rates up to 8 Mbytes/s using a non-interlocked handshake. Actual transfer rates depend on host architecture and system configuration.

References

ANSI/IEEE Standard 488.1-1987. IEEE Standard Digital Interface for Programmable Instrumentation. Institute of Electrical and Electronics Engineers, Inc. 345 East 47th St., New York, NY 10017, USA.

ANSI/IEEE Standard 488.2-1987. IEEE Standard Codes, Formats, Protocols, and Common Commands. Institute of Electrical and Electronics Engineers, Inc. 345 East 47th St., New York, NY 10017, USA.

Reader Comments | Submit a comment »