|
|
|
|
The GPIB FAQ Version 1.0
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.
 About GPIB |
The Bus structure |
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.
Who put this FAQ together?
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.
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.
About 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.
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.
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.
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.
GPIB setup
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). 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.
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. Signal Pin Controlled by Function
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.
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.
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 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:
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.
GPIB controllers
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:
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.
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.
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.
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
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.
IEEE488.2
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.
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.
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. The command tree does not allow you to descend along this particular path. :SENS:VOLT:RANG: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.
REMOTE operation Command Termination
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. |
