 |
||
 |
|
 |
 |
 |
|||
 |
 | |||
|
||||
|
|||||||||||||||
|
|||||||||||||||
|
Overview of IEEE - 488 ( Printable Version ) |
|
INTRODUCTION IEEE-488 refers to the Institute of Electrical and Electronics Engineers (IEEE) Standard number 488. This standard was first established in 1978, 13 years after Hewlett-Packard (HP) of Palo Alto, CA, began work to enable its broad range of instruments to communicate with one another and with “host” computers. At the time of its development, IEEE-488 was particularly well-suited for instrument applications when compared with the alternatives. In essence, IEEE-488 comprises a “bus on a cable,” providing both a parallel data transfer path on eight lines and eight dedicated control lines. Given the demands of the times, its nominal 1 Mbyte/sec maximum data transfer rate seemed quite adequate; even today, IEEE-488 is sufficiently powerful for many highly sophisticated and demanding applications. However, IEEE-488, as originally defined, left some ambiguities in the specifics of controller-instrument interaction and communication. While these open issues were likely intended to give instrument and controller designers some latitude, the result was confusion and compatibility problems among instruments from different manufacturers. During the 1980’s, a new layer was added to the IEEE- 488 standard, IEEE-488.2. The original standard was re-designated IEEE-488.1. IEEE-488.2 provides for a minimum set of capabilities among “controllers” and “devices,” as well as for more specific content and structure of messages and communications protocols. IEEE-488.2 is fully backward compatible with IEEE- 488.1; the use of a “488.2”-compliant controller affords the ability to use the new protocols available with “488.2” instruments while retaining the ability to communicate with and control “488.1”-compliant instruments and associated vendor idiosyncrasies. Today, IEEE-488 is the most widely recognized and used method for communication among scientific and engineering instruments. Major stand-alone general purpose instrument vendors include IEEE-488 interfaces in their products. Many vertical market instrument makers also rely on IEEE-488 for data communications and control. IEEE-488 controllers support a variety of personal computers, from the IBM PC/XT/AT and PS/2 and compatibles to the multifaceted Macintosh family. Some of these controllers are plug-in cards; others are protocol converters ( e.g., SCSI-to-IEEE-488). All provide at least IEEE-488.1 in compliance, and a growing number adhere to “488.2.” GENERAL INFORMATION The IEEE-488 interface, sometimes called the General Purpose Interface Bus (GPIB), is a general purpose digital interface system that can be used to transfer data between two or more devices. It is particularly wellsuited for interconnecting computers and instruments. Some of its key features are: • Up to 15 devices may be connected to one bus • Total bus length may be up to 20 m and the distance between devices may be up to 2 m • Communication is digital (as opposed to analog) and messages are sent one byte (8 bits) at a time • Message transactions are hardware handshaked • Data rates may be up to 1 Mbyte/sec Mechanical Specifications CONNECTOR The IEEE-488 connector is a 24-pin connector. Devices on the IEEE-488 bus have female receptacles; interconnecting cables have the mating male connectors. Connecting cables will typically have male and female receptacles wired in parallel at each connecting head to allow parallel connection of cables at a device and/or to allow daisychaining between devices. INTERCONNECTION CABLING Any individual IEEE-488 bus is limited to 15 devices including the controller. However, the IEEE-488 specification limits the total length of all cabling used to interconnect devices on a common bus to 20 m, or 2 m times the number of interconnected devices (up to 20 m). Cable lengths between devices may vary, as long as total cable length does not exceed these restrictions. Devices may be interconnected in a star or linear topology, or in a combination of the two, as long as the distance limits are observed. For maximum data transfer rates, the total cable length should be reduced to 15 m, with the average interdevice cable 1 m or less. Electrical Specifications BUS LINES The IEEE-488 bus is a multidrop interface in which all connected devices have access to the bus lines. The 24 bus lines group into four categories: • Data Lines - Eight lines (DIO1 through DIO8) used to transfer information (data and commands) between devices on the bus, one byte at a time. • Handshake Lines - Three lines used to handshake the transfer of information across the data lines: DAV: Data Valid NDAC: Not Data Accepted NRFD: Not Ready for Data • Bus Management Lines - Five lines used for general control and coordination of bus activities: ATN: Attention I FC: Interface Clear REN: Remote Enable SRQ: Service Request EOI: End or Identify • Ground Lines - Eight lines used for shielding and signal returns: One Shield One General Signal Ground Six logic ground lines paired off with ATN, SRQ, IFC, NDAC, NRFD and DAV HANDSHAKING The IEEE-488 bus uses three handshake lines in a “We're ready - Here's the data - We've got it” sequence to transfer information across the data bus. The handshake protocol assures reliable data transfer at the rate determined by the slowest Listener. The handshake lines, like all other IEEE-488 lines, are active low. DAV is controlled by the Active Talker. Before sending any data, the Talker verifies that NDAC is asserted (low) which indicates that all Listeners have accepted the previous data byte. The Talker then places a byte onto the data lines and waits until NRFD is unasserted (high), indicating that all Addressed Listeners are ready to accept the information. When NRFD and NDAC are in the proper state, the Talker asserts DAV (active low) to indicate that the data on the bus is valid. NRFD is used by the Listeners to inform the Talker that they are ready to accept the new data. The Talker must wait for each Listener to unassert this line (high), which they do at their own rates when they are ready for more data. This assures that all devices accepting the information are ready to receive it. NDAC, also controlled by the Listeners, indicates to the Talker that each device addressed to listen has accepted the information. Each device releases NDAC (high) at its own rate, but NDAC does not go high until the slowest Listener has accepted the data byte. This type of handshaking permits multiple devices to receive data from a single data transmitter on the bus. All active receiving devices participate in the data handshaking on a byte-by-byte basis and operate the NDAC and NRFD lines in a “wired-or” scheme so that the slowest active device determines the rate at which the data transfers take place. IEEE-488 FUNCTIONS When information is placed on the data lines, it can represent either a data byte or a command. If the Attention bus management line (ATN) is asserted while the data is transferred, then the data lines are carrying a multiline command to be received by every bus device. If ATN is not asserted, then a data byte is being transferred, and only the Active Listeners receive that byte. The IEEE-488 bus also has a number of uniline commands that are carried on a single bus management line. For example, the Interface Clear (IFC) line, when asserted, sends the Interface Clear command to every bus device, causing each to reset its IEEE-488 bus interface. ADDRESSING The IEEE-488 standard normally permits up to 15 devices to be configured within one system. Each of these devices has a unique bus address, a number from 0 to 30. Address limits can be circumvented directly by the use of bus expanders or indirectly through the use of an isolator or an extender. A device becomes Addressed to Talk when it receives a Talk Address Group (TAG) multiline command (a byte transferred with ATN asserted) specifying its own address from the Active Controller. Similarly, it becomes Addressed to Listen when it receives a Listen Address Group (LAG) multiline command. Other address commands include My Talk Address (MTA) and My Listen Address (MLA), which are the TAG and LAG commands of the Active Controller. The secondary Command Group (SCG) is used to refer to subaddresses or subfunctions within a particular device. This permits direct access and control of the subdevices or subinstruments embedded within complex devices or instruments. THE SYSTEM CONTROLLER The System Controller, usually a computer with an IEEE- 488 board installed, always retains ultimate control of the bus. When the system is first powered up, the System Controller is the Active Controller and controls all bus transactions. The System Controller may Pass Control to a device, making it the New Active Controller, which may then Pass Control to yet another device. Even if it is not the Active Controller, the System Controller maintains exclusive control of the Interface Clear (IFC) and Remote Enable (REN) bus management lines and can take control of the bus whenever it desires. IEEE-488.2 The IEEE-488.2 standard was developed to simplify the basic process of communicating with instruments. IEEE488.2 extends the 488 standard with code, format and protocol standardization and serves to resolve issues left open in 488.1. IEEE-488.2 details preferred implementation of many of the issues that were either optional or unspecified on the first standard. IEEE-488.1 covers the key physical issues (connector type, bus length, maximum number of instruments, etc.), electrical issues (open collector TTL, tristate) and low-level protocols (device addressing, control passing and data handshaking/timing). Four basic device functions (Talker, Listener, Controller and System Controller) are specified, as are capability subsets for each type of device. A number of items not covered by 488.1 can cause problems for the test engineer, particularly regarding equipment compatibility and data corruption. For example, 488.1 does not cover these specifications: • Minimum Device Capability Requirements No minimum set of requirements is mandated in IEEE- 488.1 for Talkers, Listeners, Controllers or System Controllers. Hence, a device may implement all, or only some, of the capability sets set forth in 488.1, giving rise to systems containing devices with varying levels of abilities. The Controller, in such a situation, has no guarantee of a basic communication subset among system devices. This can lead to confusion for the system operator and miscommunication between devices. • Data Coding, Formats and Message Protocol Under 488.1, the messages transferred between the Controller and a device are entirely at the discretion of the device manufacturer. The use of ASCII, binary or some other form of data code and the choice of terminators such as carriage-return or EOI is arbitrary. Also, the sequence of the sending of commands and the reading of their responses is unspecified and varies from instrument to instrument. • Definition of the Status Byte 488.1 defines a status byte and one bit within, but the meaning of the other seven bits is at the discretion of the device designer. This forces the user to provide a unique interpretation of each bit of the status byte. Also, the relationship between the status byte and the device's other internal status registers is unspecified. DRIVER SOFTWARE FOR IBM PC Great variety is found in the software required to complete the interface between the user's program and the IEEE instruments. Two fundamental techniques are used: the DOS device driver and the subroutine library. These are not mutually exclusive, as subroutine libraries can be implemented via a DOS device driver. DOS DEVICE DRIVER A popular form of device driver used by several IEEE- 488 controller providers is the Terminate and Stay Resident (TSR) DOS device driver approach. In this method, the driver code is stored in memory as a TSR and waits for access by an application program, much as Borland’s Sidekick waits for user “hot key” input. OMEGA’s 488 driver establishes a file I/O link with DOS, just as DOS provides file I/O links for system devices such as the keyboard/screen, printer or serial port. These DOS I/O files may be accessed directly from DOS, from programs with file I/O capability, including spreadsheets such as Lotus 1-2-3 and Borland's Quattro, and from most programming languages. These files provide a direct link to the IEEE-488 bus using HP-style English language commands. This style of Applications Program Interface (API) is often referred to as Character Command Language (CCL), as the IEEE commands are sent as ASCII strings to the driver via the API’s file I/O links through DOS. Controlling Instruments from Any Language Just as DOS and spreadsheets can access IEEE instruments directly using the file I/O services provided by DOS for device drivers, most programming languages also can use file I/O to quickly and easily access the IEEE-488 bus. SUBROUTINE IEEE-488 DRIVER INTERFACE An alternative means of controlling the IEEE-488 hardware is via subroutine calls from high level languages. This method has the advantage of minimizing the overhead of DOS device driver services and the ASCII message (CCL) parser and interpreter. Disadvantages include the loss of the convenience and effectiveness of accessing the IEEE-488 bus from a wide variety of applications programs, as well as from DOS. Also, the use of subroutines, even those with easy-to-use HP-style commands, typically requires compiling and linking to run even simple test codes. Some IEEE controller implementations on the IBM PC give the user the choice of subroutine calls or CCL. IEEE-488 SUBROUTINE CONTROL LIBRARIES The logical complement to subroutine interfaces for a TSR DOS device driver are subroutine libraries that directly access the IEEE-488 hardware from a high-level language with code that is compiled and linked directly into the user’s program. This approach eliminates the DOS device driver, integrating the IEEE-488 control functions directly into the applications program code. This method has the potential for the highest performance, as it eliminates possible DOS effects on the speed of commands and data. MICROSOFT WINDOWS COMPATIBILITY The growing popularity of the Windows 3.0 Graphical User Interface (GUI) is rapidly spreading to test and measurement applications. Until 1991, few tools were available for the end user to build Windows applications. Now, tools such as Microsoft's Visual Basic and Borland’s C++ provide GUI development interfaces that allow users to draw windows and fill them with buttons, scroll bars and dialog boxes. Soon, these tools (and the tools, libraries and utilities that follow) will be widely used by developers of IEEE-488 test programs. IEEE-488 controller package vendors will adapt their offerings to be compatible with Windows, so users will be able to apply Windows solutions to their measurement problems. As these new Windows-oriented drivers and packages debut, there will undoubtedly be a broad range of solutions offered to the end user. It is important to know and understand what makes Windows and Windows applications different from DOS, and what features an IEEE-488 driver should have in order to make the most of the Windows environment. Users should keep the following issues in mind when reviewing new offerings: • Is the software written as a Windows application, or is it merely a port of DOS software? Windows performs its own memory management functions; typical DOS ports to Windows do not permit Windows to dynamically allocate memory use, which can lead to “Unrecoverable Application Errors.” As Windows is an event-based system, it provides extensive event handling facilities; Windows applications should take advantage of them. Windows has no equivalent of the TSR concept used with DOS. Although some DOS TSR’s will function while Windows is running, their operation can be erratic and unpredictable. • Will the driver support concurrent access of different peripherals on a single interface by multiple Windows applications? Windows’ pseudo muItitasking is one of its reasons for being. • Will the driver service multiple bus adaptor boards? • Is the driver IEEE-488.2 compliant? |
 |
|
  |
|||
 |
||||