18-01-2013, 11:06 AM
GPIB TUTORIAL
GPIB.docx (Size: 77.18 KB / Downloads: 23)
BACKGROUND
Instrumentation has always leveraged off widely used electronics technology to drive its innovation. The jeweled movement of the clock was first used to build analog meters. The variable capacitor, the variable resistor, and the vacuum tube from radios were used to pioneer the first electronic instruments. Display technology was leveraged off the television for use in oscilloscopes and analyzers.
Today, cost-effective and powerful desktop and notebook computers are paving the way for new types of instruments --virtual instruments--. Virtual instruments are designed and built by the user to match specific needs by leveraging off the power and low cost of PCs and workstations.
Software is the key to virtual instruments. Application software empowers the user with the tools necessary to build virtual instruments and expand their functionality by providing connectivity to the enormous capabilities of PCs, workstations, and their assortment of applications, boosting performance, flexibility, reusability and reconfigurability while diminishing at the same time development and maintenance costs.
INTRODUCTION
In 1965, Hewlett-Packard designed the Hewlett-Packard Interface Bus ( HP-IB ) to connect their line of programmable instruments to their computers. Because of its high transfer rates (nominally 1 Mbytes/s), this interface bus quickly gained popularity. It was later accepted as IEEE Standard 488-1975, and has evolved to ANSI/IEEE Standard 488.1-1987. Today, the name G eneral Purpose Interface Bus (GPIB) is more widely used than HP-IB. ANSI/IEEE 488.2-1987 strengthened the original standard by defining precisely how controllers and instruments communicate. S tandard Commands for Programmable Instruments (SCPI) took the command structures defined in IEEE 488.2 and created a single, comprehensive programming command set that is used with any SCPI instrument. Figure 1 summarizes GPIB history.
TYPES OF GPIB MESSAGES
GPIB devices communicate with other GPIB devices by sending device-dependent messages and interface messages through the interface system.
• Device-dependent messages, often called data or data messages, contain device-specific information, such as programming instructions, measurement results, machine status, and data files.
• Interface messages manage the bus. Usually called commands or command messages, interface messages perform such functions as initializing the bus, addressing and unaddressing devices, and setting device modes for remote or local programming.
The term "command" as used here should not be confused with some device instructions that are also called commands. Such device-specific commands are actually data messages as far as the GPIB interface system itself is concerned.
TALKERS, LISTENERS AND CONTROLLERS
GPIB Devices can be Talkers, Listeners, and/or Controllers. A Talker sends data messages to one or more Listeners, which receive the data. The Controller manages the flow of information on the GPIB by sending commands to all devices. A digital voltmeter, for example, is a Talker and is also a Listener.
The GPIB is like an ordinary computer bus, except that a computer has its circuit cards interconnected via a backplane - the GPIB has stand-alone devices interconnected by standard cables.
The role of the GPIB Controller is comparable to the role of a computer CPU, but a better analogy is to compare the Controller to the switching center of a city telephone system.
The switching center (Controller) monitors the communications network (GPIB). When the center (Controller) notices that a party (device) wants to make a call (send a data message), it connects the caller (Talker) to the receiver (Listener).
The Controller usually addresses (or enables) a Talker and a Listener before the Talker can send its message to the Listener. After the message is transmitted, the Controller may address other Talkers and Listeners.
Some GPIB configurations do not require a Controller. For example, a device that is always a Talker, called a talk-only device, is connected to one or more listen-only devices.
A Controller is necessary when the active or addressed Talker or Listener must be changed. The Controller function is usually handled by a computer.
A computer with the appropriate hardware and software could perform the roles of Talker/Listener and Controller.
THE CONTROLLER-IN-CHARGE AND SYSTEM CONTROLLER
Although there can be multiple Controllers on the GPIB, at any time only one Controller is the Controller-In-Charge (CIC). Active control can be passed from the current CIC to an idle Controller. Only the System Controller can make itself the CIC.
GPIB SIGNALS AND LINES
The GPIB interface system consists of 16 signal lines and eight ground-return or shield-drain lines. The 16 signal lines, discussed below, are grouped into data lines (eight), handshake lines (three), and interface management lines (five) (see Figure 2).
Data Lines
The eight data lines, DIO1 through DIO8, carry both data and command messages. The state of the Attention (ATN) line determines whether the information is data or commands. All commands and most data use the 7-bit ASCII or ISO code set, in which case the eighth bit, DIO8, is either unused or used for parity.
Handshake Lines
Three lines asynchronously control the transfer of message bytes between devices. The process is called a 3-wire interlocked handshake. It guarantees that message bytes on the data lines are sent and received without transmission error.
• NRFD (not ready for data) - Indicates when a device is ready or not ready to receive a message byte. The line is driven by all devices when receiving commands, by Listeners when receiving data messages, and by the Talker when enabling the HS488 protocol.
CONFIGURATION REQUIREMENTS
To achieve the high data transfer rate for which the GPIB was designed, the physical distance between devices and the number of devices on the bus are limited.
The following restrictions are typical for normal operation:
• A maximum separation of 4 m between any two devices and an average separation of 2 m over the entire bus
• A maximum total cable length of 20 m
• No more than 15 device loads connected to each bus, with no less than two-thirds powered on
For higher speed systems using the 3-wire IEEE 488.1 handshake (T1 delay = 350 ns), and HS488 systems, the following restrictions apply:
• A maximum total cable length of 15 m with a device load per 1 m cable
• All devices should be powered on
CONTROLLERS
Although IEEE 488.2 had less impact on Controllers than it did on instruments, there are several requirements and optional improvements for Controllers that made an IEEE 488.2 Controller a necessary component of test systems. IEEE 488.2 precisely defined the way IEEE 488.2 Controllers send commands and data and added functionality. Because of these IEEE 488.2 Controller requirements, instrument manufacturers can design more compatible and efficient instruments. The benefits of this standardization for the test system developer are reduced development time and cost, because it solves the problems caused by instrument incompatibilities, varying command structures, and data formats.