The GPIB FAQ 1.0

 

Home
Up

 

 

 

The GPIB FAQ Version 1.0
(c) 2000 Vincent Himpe


This article is a collection of information sources on the GPIB Bus. The document exists as a HTML file and as a iSilo document for Palm (tm) based organisers. You are free to use , copy , distribute and disclose the contents of this faq to anyone provided no money is asked for the copy.

Use of information in this faq is solely at the users risk. No liability will be accepted for any damage or loss resulting from the use or abuse of information contained in this document.

The GPIB FAQ Version 1.0

Preface
About this FAQ
Who put it together
How can i contribute to it
Where will it be posted ?
May i distribute this FAQ or post it somewhere else ?
About GPIB
History of the GPIB bus
The Bus structure


Preface

Hi and welcome to the latest edition of the I2C FAQ. Over the years I have been supporting people in their attempt to master this bus. I have collected a total of over 500 e-mails with questions ranging from beginner level to things that even I could not solve in 1-2-3. I Will try to summarize the knowledge I obtained in this revision of the FAQ.

I Would like to thank all the people who have bombarded me with interesting stuff and questions about I2C. I am also happy that my little knowledge could help.

Vincent September 1st 2000.
Back to Main Index

About this FAQ

Who put this FAQ together?
I put this FAQ together as a result of my own searching for information about the GPIB bus. I have been playing with the bus for some time and, although I am not an expert on this matter, i think my, and other people's, experiences with the GPIB can solve common problems.
Back to Main Index


How can I contribute to this FAQ?
If you have any suggestions or additions please inform me or the future maintainer of the FAQ.You can contact me by e-mail : vincent.himpe@pi.be ( valid until 1 Jan 2001 ) after that E-mail will most likely no longer be possible.

I hope that those of you who know of interesting items for this FAQ will share with everyone. A good amount of stuff is turning up thanks to everyone's help. If you have a website you can put the FAQ or a link to the FAQ online there.
Back to Main Index


What newsgroups will it be posted in?
This FAQ has been posted a last time to the following newsgroup: sci.electronics.design
Back to Main Index


May I distribute this FAQ ?
I am putting no restrictions on the use of this FAQ except - It must be distributed in its entirety with the copyright notice, and no financial gain may be realized from it. After all, I have spent an lot of time on this. The only thing that I intend to gain from it is more information on GPIB.

The copyright does not limit the use of this FAQ for noncommercial purposes. I hereby give my permission to one and all to pass this FAQ around and post it wherever you want - as long as it is not for financial gain.

You are allowed to distribute portions of the FAQ as long as you incorporate the following note. 'Taken from The GPIB FAQ' and provide a link to its storage on the internet.
Back to Main Index

About GPIB bus.


History of the GPIB bus

In 1965, Hewlett-Packard ( now Agilent ), a major manufacturer of electronic test instruments, wanted to develop a means by which any of its instruments could communicate and exchange data with any other. The method that their engineers developed was a hardware standard and communications protocol that became known as the HP-IB (Hewlett-Packard Instrumentation Bus).

This bus became quite popular, and in 1975 it was adopted by the IEEE as a standard-the IEEE-488 bus, also widely known as the general purpose instrumentation bus (GPIB). About 10 years later, the standard was revised to resolve a number of ambiguities that were not spelled out in the original standard. This newer version of the standard is known as IEEE-488.2.
Back to Main Index


Purpose of the GPIB bus

Like explained before the main purpose of the bus is to connect Test and Measurement (T&M) equipment and exchange data and commands between them. In the 'medieval' times where computers were still scarce this was a very futuristic idea. Today the bus is still used for this primary purpose, however it goes further. There are today a number of GPIB units that allow you to run this bus even via Ethernet. At a certain point there existed even harddisks and monitors featuring a GPIB connection.

Back to Main Index


Capabilities

Because of the parallel nature of the bus, it has a high transfer rate. Modern controllers can easily reach transfers in the order of 4 to 5 Mbyte a second. That is about 5 time faster than ethernet ! The bus allows to have a maximum of 2 masters that can 'swap' places and become active controllers. You can use this bus to transfer any kind of information. A number of special modes allow you to access multiple instruments at the same time ( Serial or Parallel polling ) . The slaves are capable of sending a Service Request (SRQ) to the master. This acts like an interrupt. The master can also lock out the 'human' users from further operating the machines via the front panel. To do this the master simply puts the machines in Remote mode and then asserts the REN ( remote Enable) line. These special things will be explained later.
Back to Main Index


The GPIB bus structure

Although the GPIB interface is in fact a fairly general purpose bus, its primary use is to connect one or more GPIB-compatible instruments to a PC, and several thousand such GPIB products are available on the market. It allows data to be exchanged a byte at a time among several different devices at speeds of 100K/sec to 10MB/sec .

There is also an effective handshaking protocol that synchronizes the transfers. At any given time, one device has the responsibility of being the active bus controller, which coordinates all data transfers; there is also a defined mechanism that allows another device to take over as the new controller. In practice, however, a PC with an IEEE 488 card in it is nearly always the permanent controller of the bus. The controller can assign itself and other devices to be either talkers (devices that transmit data) or listeners (devices that receive data) with the restriction that only one device can talk at a time.
Back to Main Index

GPIB setup


A typical example of a GPIB setup is depicted in the next picture.

The left part of the image shows a Daisy-chain configuration while the right part shows a star configuration.
The PC, acting as the controller, is connected to several different devices that can be

listeners only
both talkers and listeners (at different times), or in rare cases,
talkers only.

A 16-wire cable connects the devices together, going from one device to the next to the next. There can be up to 15 different devices on a GPIB system, and the total cable length can be up to 20 meters long, provided the devices on it are spaced no more than 4 meters apart (with a 2-meter maximum spacing strongly recommended).

The 24-pin Type 57 micro-ribbon connectors used for the GPIB have a unique stackable design,

which allows one connector to be directly plugged into the back of another connector, as indicated in the figure. This stackability also allows you to connect devices in a star configuration with separate cables going to each device from a single output connector on the PC's GPIB card.

To understand how a typical GPIB system works, consider an example. Suppose you want to test a frequency doubler, (a device that phase-locks to the frequency of a sine wave at its input and produces an output that's exactly twice the input frequency). What we want to know is the range of input frequencies over which the device works properly and how its operating range is affected by variations in its power supply voltage. After initializing the system, the controller (the GPIB card in the PC) tells the waveform generator to set itself to the desired output frequency range and tells the counter to set itself to the desired input frequency range.

The controller then starts the test procedure by telling the power supply to output a given voltage, telling the waveform generator to output a sine wave of the desired frequency and amplitude, and then commanding the counter to read the output frequency of the device under test and send the value back to the controller. By repeating this test procedure sequence with different values of the power supply voltage and waveform generator frequency, the frequency-doubler operating range can be completely tested.

For each one of the preceding actions, the controller issues commands to make a given device (or devices) a listener so that the device can receive each message (a control setting, a frequency value, and so on) and to make another device (often the controller itself) be the talker that sends the message. This all sounds great, but you might wonder how information transfers are coordinated so that listeners having different speeds can all read messages accurately and how you program the devices to be talkers or listeners. To answer these questions, let's first look at the GPIB hardware and examine what the various data and control lines are and how they operate.
Back to Main Index

GPIB signals

The 24 pin micro-ribbon carries a number of signals that together for the GPIB bus. The GPIB has eight bi-directional data lines, DIO1-D108, three handshake lines, and five bus management lines. The signal names, their connector pin numbers, the source that drives the signal, and a brief synopsis of their functions are given in the picture below.

It's important to note that all the GPIB signals are active low, but the IEEE-488 standard doesn't use over-scores on the signal names to indicate this. We'll follow that convention in the section; just keep in mind that in this section, a low on a given line means the signal is asserted (i.e., true). Signals on the data lines are also inverted (1 = low).

Signal Pin Controlled by Function

DIOl - D108 1-4 / 13-16 controller/talker 8-bit data/command lines
NRFD (Not ready for data) 7 Listeners Handshake line
NDAC (No Data Accepted) 8 Listeners Handshake line
DAV (Data valid) 6 controller/talker handshake line
ATN (attention) 11 controller distinguishes commands from data
SRQ (Service Request) 10 any device used to request service from the controller
IFC (Interface clear) 9 controller initializes the GPIB bus
REN (remote enable) 17 controller places device in remote mode
EOI (End or Identify) 5 controller/talker marks end of message or (with ATN) signals parallel poll by controller

In addition to the 16 signal wires, a GPIB cable contains several ground wires. The three handshake signals and the bus management signals ATN, SRQ, and IFC have their own separate ground wires that run through the cable along with the signals as twisted pairs of wires. This helps to reduce cross-talk and noise pickup on these key control lines.

There is also a signal ground wire and a shield ground wire. The latter is a ground for the cable shielding, which is a sheath of fine wire braid that surrounds the entire length of the cable and shields the wires inside from external noise sources.
Back to Main Index


Physical interface
Each of the signal lines is driven by a driver/receiver circuit like that shown in the figure below.

As shown in the figure above, the connection for every signal line on each device must contain its own Thevenin terminator to prevent reflections on the bus. This distributed line termination scheme is the reason why devices should be spaced no more than 2 meters apart on the bus.

Open collector drivers can be used on all signal lines. The drawback is that the time required for a logic signal to make a low to high transition can be significant because the cable wiring behaves like a capacitor that must be charged up through the termination resistor to go from low to high.

Tri-state drivers provide better performance and can be used on all lines except NRFD, NDAC, and SRQ, all of which need the wired-OR capability of open-collector drivers. The terminator resistors also ensure that any un-driven line is pulled up to a logic high state.
Back to Main Index

Information transfer

Two types of information can be transferred over the GPIB bus: commands and data. When both the controller drives Attention (ATN) and Data Valid (DAV) low, the byte value on DIOL-D108 represents a command to one or more devices. Such commands enable remote operation of devices on the GPIB and assign them to be talkers or listeners, and so on.

When ATN is high and DAV is low, the byte value on the data bus is data. Hence, ATN is a switch that identifies whether the data bus value is a command or data; DAV low means what its name says-the data on DIO1-DIO8 is valid for all listeners to read.

All bus transfers-both controller commands and talker-listener data transfers- take place using Hewlett-Packard's patented three-wire handshake. All devices must
handshake when commands (ATN low) are being sent, but only listeners handshake for data transmission. This allows high-speed transmission between two fast devices even when there are much slower devices present on the same bus. The figure below presents a timing diagram for a command followed by a 1-byte data transfer, showing how the handshake signals work.

To better understand how the handshake operates, here is the sequence of events that occurs when the controller sends a command to the devices on the bus:

Before putting a new command on the bus, the controller checks to see if the Not Ready For Data (NRFD) line is high. Any device that's not ready to accept another data byte holds NRFD low. Thus, thanks to the open-collector connection of the NRFD line, it can go high only when all devices are ready to accept a new command byte.
The controller sets ATN low to indicate a command is being sent, places the command code on the data lines, and, after a delay to allow the DIO lines to settle, pulls DAV low to indicate that a valid command is present on DIO1-D108.
When each device sees DAV go low, the device pulls its NRFD line low to indicate that it knows a new byte is present, but that it hasn't yet received and stored it.
Once each device has stored the command byte, it releases the No Data Accepted (NDAC) line to indicate that it's accepted the byte. When the slowest device has released NDAC, this open-collector line will finally go high.
The controller now knows that all devices have accepted the command, so it sets DAV high and removes the command byte from the data lines.
On seeing DAV go high, each device sets its NDAC line low again so that it's in the proper state for the next data transfer.
When it's handled the command just received and is ready to receive the next byte, each device releases its NRFD line. As a result, NRFD will finally go high when the slowest device is ready.

The same sequence of events occurs when a talker sends data to one or more listeners. The only difference is that for a data transfer the ATN line is high, and only those devices that are currently configured to be listeners participate in the handshake. Non-listeners do not drive the NRFD and NDAC lines.

You may be wondering why such a complex handshake is used here. The answer is that in nearly all other bus systems such as ISA or SCSI, data is sent from a single source to a single receiver. In a GPIB system, however, there can be more than one listener and the three-wire system prevents multiple acceptance of data by a fast listener while a slow one is still busy accepting the data.

When messages (either commands or data) are sent from one GPIB device to another, the programmer doesn't need to worry about the details of the handshake. GPIB interfaces in instruments and GPIB controller cards for PCs use sophisticated ASICs (application specific integrated circuits) that constitute a complete (or nearly so) GPIB interface on a chip.
Back to Main Index

GPIB controllers


A good example of such a controller chip is the National Instruments TNT4882. This 100-pin chip contains both a complete ISA bus interface and a complete GPIB interface. You only need to provide a 40-MHz clock signal to create a fully functional GPIB controller. The chip appears to the PC as a set of read/write registers accessible as 16 consecutive I/O ports. Writing appropriate values into the registers allows you to control the GPIB bus any way you want.

Normally you don't program the interface chip's registers directly either. When you buy a GPIB card for a PC, it comes with software drivers that provide a set of high-level functions you can call to communicate with and and control the instruments on the GPIB. Since these functions differ from one board manufacturer to another, they won't be discussed here.

However for completenesshere is a list of GPIB controllers that exist or have existed:
 

Intel 8291: The basic slave GPIB chip. Needs a 8292 to become master.
Intel 8292: Master functionality for 8291.
Intel 8293: The IO drivers for the 8291 / 8292 chips.
Motorola 68488: GPIB for the 68xx family from motorola
NEC uPD7210: Most used GPIb controller. Is basically an integration of the intel chipset into a single chip.
Philips HEF4743: Slave controller only.
TI TMS9914: the grand-daddy of them all. For TI processors with bit reversed databus ( can be a real pain if writing software for it. If the datasheet talks about bit 1 in a register you need to write bit 6 !.
NI TNT488: All in one GPIB controller with integrated drivers. feature standard mode and ISA mode. ISA mode changes pinout to hook it up to a PC motherboard directly.

Besides these chips there are a number of other vendors like INES ( Germany ) CEC ( Capital Equipment USA ) and IO-Data / Data translation that have made their own chips. these are based either on the TMS9914 or the NEC UPD7210. Some are even switchable by pulling a certain pin high or low. The functionality remains but in some cases FIFO's have been added inside the chip or the output drivers are on board.
Back to Main Index

Controlling a device on GPIB

Let's next see how each device in a GPIB system can be initialized by the controller and then commanded to send or receive data. To permit individual communications with the devices on a GPIB system, each device must have a 5-bit GPIB address. This address is normally set by means of switches on the back of a GPIB instrument or by using controls on its front panel.

Any address between 0 and 11110 (address 30) may be used, except that by convention, address 0 is usually reserved for the controller's address. Address 31 is used for the un-talk and un-listen commands (see next paragraph) and thus can't be used as a device address. Note that even though there are 31 possible primary addresses, a maximum of 15 devices (including the controller) can be attached to the GPIB at a given time.

The 5-bit address set in the device's switches actually specifies two different address codes that are used to assign devices to be talkers or listeners. To command a device to be a listener on the bus, the controller sends a command (ATN low) with the device's My Listen Address (MLA) on DIO1-D108. The MLA is obtained by adding 20h to the 5-bit GPIB address.

Similarly, a device is commanded to be a talker by sending a command with the device's My Talk Address (MTA) on DIO1-D108. The MTA is obtained by adding 40h to the 5-bit address. For example, if the device's GPIB address is 3, then sending the command 23h (or the ASCII character '#') makes it a listener; sending the command 43h (or the ASCII character 'C') makes it a talker. The un-listen (UNL) command 3Fh (ASCII character '?') causes all current listeners to stop being listeners; the un-talk (UNT) command 5th (ASCII character'') causes the current talker to stop being a talker.

It's possible, but not very common, for devices to be extended talkers and/or listeners. Such devices have secondary addresses that provide selective access to sub-units within the device. The secondary address is sent as a second address byte after the initial one, with 60h added to the physical secondary address to distinguish it as a secondary address.
Back to Main Index


Initializing a GPIB system

To initialize a GPIB system, the first thing the controller typically does is to send the Interface Clear (IFC) command by asserting the IFC line for a few hundred microseconds on the GPIB bus. All devices on the bus must monitor this line and, upon seeing it go low, must immediately cease all bus activity and go into an idle state.

The controller will then usually assert the REN line. As long as REN remains low, listeners must switch into and stay in remote mode. In this mode, devices disable their front panel controls and allow the controller to send them commands that change any characteristics that were previously determined by knobs and switches on the front panel of the device. The programmed settings will override existing front panel control settings.

Note that the interface clear and remote enable operations are usually referred to as the transmission of Interface Clear (IFC) and Remote Enable (REN) commands. However, IFC and REN are unlike other commands (they're called uni-line commands) in that the DIO1-DIO8 lines aren't used and there is no handshaking. We're just talking about asserting a single control line.

In most cases, the controller next sends a device clear (DCL) command to each device. The DCL command places the settings of all listener's controls into a default state determined by the manufacturer of each device. Like UNT and UNL, DCL is one of about a dozen commands that are given by placing a value on the DIO lines (14h for DCL) and asserting ATN. Several more of these commands are discussed shortly in conjunction with device polling.
Back to Main Index


Exchanging data

The programming of specific device controls to their desired values is done by sending device dependent messages to the device using the specific commands that instrument understands. The format of these commands is up to the manufacturer and can vary greatly from one device to another. They are typically ASCII strings such as "FL1Z0R3" (FL1 = filtering on, Z0 = auto-zero off, R3 = 1-volt range) or ":CAL:USER;RANGE 3" (CAL:USER = perform user calibration procedure, RANGE 3 = set gain range #3).

These messages are preceded by a sequence of commands to select the talker and listener. For example, if the controller is at GPIB address 0 and a voltmeter to be programmed is at address 03, you can set its voltage range to 1 volt by having the controller send the commands to Un-listen, Un-talk, set My Listen Address = 03, set My Talk Address = 0, and finally send the ASCII characters "R3".

All of this is done by having the controller send the string of commands 3f Sf23 55 (or equivalently the ASCII string "?# U") followed by the device dependent message
"R3". It's useful to understand that a sequence of commands can be specified as an ASCII string since many GPIB systems are programmed using an extended form of BASIC; in BASIC, sending an ASCII string is often the easiest and most compact way of sending GPIB commands or messages.
Back to Main Index


EOI assertion

When a multi byte message such as "FL1Z0R3" is sent from a talker to a listener, the listener needs to have some way to know when the message is complete and the last byte has been sent.

The end of message signal is given by requiring the talker to assert the End Or Identify (EOI) line as the last byte of the message is placed on the data lines. The reason for the EOI line's strange name is that it's a dual purpose line. In addition to signaling the end of a message, it's also used to initiate a parallel poll (see below). Another technique used by some GPIB instruments is to indicate the end of message by sending an ASCII line feed character (= Oah) as the last byte.
Back to Main Index

IEEE488.2


The original IEEE-488 standard left the codes, formats, and protocols for device-dependent messages and other kinds of information completely up to the device manufacturers.Furthermore, the GPIB capabilities of instruments from different manufacturers varied greatly.

Not surprisingly, the result was that software drivers written for one instrument were incompatible with the drivers for any other instrument, even if the instruments were quite similar. When you bought a GPIB interface card, you needed to obtain software drivers that were written specifically for every instrument you were going to put in the system. To help eliminate these incompatibility problems, the IEEE-488.2 revision of the original standard specified a set of data formats, message protocols, and common commands that every IEEE-488.2 compliant device must adhere to.

In general, messages and information sent over the GPIB are in the form of ASCII strings, with well-defined formats for numbers. For example, the number 20 could be sent as any of the ASCII strings "20", "20.0", or "2.0e+1". There is also provision for sending blocks of binary data using the format #nn.<binary data> where nn is a two-digit ASCII number giving the number of bytes of binary data that follows. IEEE-488.2 also defines a set of standard protocols for instrument status reporting.
Back to Main Index


Common Command Set
A common command set of 39 standard commands is defined by IEEE-488.2. All compliant devices must implement 13 of these, with 5 more being required if certain instrument capabilities are present.

The other common commands are optional. Each of the commands is sent over the bus as an ASCII string with ATN false, just like device-dependent messages are, and they have the form *name, where name is a three-letter mnemonic for the common command. The leading asterisk identifies the command as being a member of the common command set.

Two examples of such commands are ‘*CLS’ which clears an instrument's status registers, and ‘*IDN?’, which causes the device to provide its device identification string. The second example here is 1 of the common command queries. The query mnemonics all end with question mark and cause the device to transmit some requested piece of information the next time it's made into a talker.
Back to Main Index


Command Description

*CLS Clear status command : Basically resets any errors
*ESE Standard Events Status Enable
*ESE? Standard Events Status Enable Query
*ESR? Standard Events Status register Query
*IDN? Identification Query
*OPC Operation Complete Command
*OPC? Operation Complete Query
*RST Reset command
*SRE Service request enable command
*SRE? Service request enable query
*STB? Read status byte query
*TST? Self test query
*WAI? Wait to continue command

Back to Main Index


SCPI command structure

At about the same time IEE488.2 was introduced a formal proposal was made to further structure the software level of the GPIB interface. The idea was to define a uniform command dictionary that could be understood by all instruments implementing similar functions. This proposal was formalized into the Standard Commands for Programmable Instruments (SCPI) document. Today , almost every new instrument being developed follows this specification.

SCPI organizes and ordens the commands an instrument understands into functional groups. A rich ‘keyword’ set has been developed that allows you to design an instruction set for any kind of instrument. However due to the complexity of modern instruments , the SCPI standard is evolving as well.

SPCI commands obey to a strict hierarchical structure. The SCPI command set is to be seen as a tree originating at the root command and dispersing into different branches depending on the function required.

Another feature of the SCPI specification is that parts of the command keyword can be omitted. Everything that is specified in UPPER case is required.
Everything written in lowercase may be omitted. This allows for speed optimization over the GPIB bus without really compromising readability.
Each command is preceded by a colon (:) . The following would be valid commands:
:SENSe:VOLTage:RANGe:AUTO<EOI>
:SENS:VOLT:RANG:AUTO<EOI>
:SENS:POWer:RANG:UPPer<EOI>
:TRIG:EXTernal:FALLING<EOI>
The following would be an illegal command:
:SENS POWer:EXTernal:FALLING<EOI>

The command tree does not allow you to descend along this particular path.
The colon preceding the SCPI command forces the instrument to start at the root level. If you
don’t send a colon before a command you remain at the same level as the last issued
statement in the command.

:SENS:VOLT:RANG:AUTO<EOI>
UPPER<EOI>
AUTO<EOI>

The first command takes the instrument down to the range configuration for sensing volts and sets it to AUTO. The second command only sends the UPPER command. Since tyhere is no preceding colon , the instrument stays at its current level in the branch of the command tree. Thus actually it will execute the command

:SENS:VOLT:RANG:UPPER<EOI>

Due to this flexibility the amount of data that needs to be sent over GPIB can be reduced to a minimum if you apply clever code optimization.


Particularities


GPIB has a number of particularities that need abetter look.

REMOTE operation
Whenever a device on the bus is accessed by a talker itbecomes a listener. During this time the local controls are diabled. That means that the listener will not respond to its keyboard or other interfaces. The instruments can receive a command to switch them to remote mode. However , the user can in most cases override this by hitting a certain function key on the instrument. If you do not want this to happen you canassert the REN line permanently. this places all devices on the bus ( except the master talker ) in a permanent remote state.

Command Termination

Last Words ...

This FAQ compiles for a last time all i know about the GPIB bus. I would like to extend greetings to those people. They had interesting problems and it was fun solving them. But the line has to stop somewhere.

Will there be future updates ? I Don't know, maybe someone will take over. Currently I am stopping all my activities to do something completely different: become a dive instructor and go live on a little island in the indian ocean far from civilisation.

I hope this FAQ may help someone out there.

Have a good life.
Vincent.