Guide to instrument and control buses
Key concepts GPIB and serial buses are the most common instrument interfaces. Bridge products convert equipment from one bus type to another. The future of instrument control will be that of a mixed I/O world. General purpose interface buses (GPIBs), also called (IEEE 488), and serial buses have been around for more than 20 yr and are the most common types present in instruments.
GPIB and serial buses are the most common instrument interfaces
Bridge products convert equipment from one bus type to another
The future of instrument control will be that of a mixed I/O world.
General purpose interface buses (GPIBs), also called (IEEE 488), and serial buses have been around for more than 20 yr and are the most common types present in instruments. While computer technology has increased exponentially in this timeframe, buses have changed little. Recently, however, new buses, such as IEEE 1394, Ethernet, and the Universal Serial Bus (USB), have emerged as candidates for instrument interfaces.
GPIB was created specifically for instrument control applications. While IEEE 488.1 focused on the electrical, mechanical, and functional specifications, IEEE 488.2 defined how controllers and instruments communicate and strengthened the original GPIB standard .
GPIB is a digital 8-bit parallel communications interface with data transfers higher than 1.5 Mbytes/sec. The bus supports one system controller and up to 14 additional instruments, with more instruments being added through expanders. GPIB cables and connectors are robust and industrial graded. Cabling is limited to less than 20 m, but with expanders can serve instruments up to 2-km away.
Currently, there is a proposal to improve the performance of GPIB from 1.5 Mbytes/sec to 8 Mbytes/sec undergoing standardization approval in IEEE. Instruments capable of high-speed GPIB transfers and compatible with existing instrumentation systems are based on the original GPIB standard.
The RS-232 serial specification most commonly controls modems and printers and usually consists of a computer interface connected to a device to be controlled. The interface is built into most computers and is very popular for instrument control applications. However, unlike GPIB, the RS-232 inter- face can only be connected to one device at a time. Furthermore, the maximum cable length without any expanders is 15 m and has data rates of less than 20 Kbytes/sec.
IEEE 1394, also known as FireWire, is a high-performance serial bus developed by Apple computer in the early 1990s. The standard handles throughput rates of 100, 200, and 400 Mbits/sec. However, the IEEE 1394 trade association is revising the specification to increase this transfer rate to 3.2 Gbits/sec.
IEEE 1394 offers great potential for high-speed applications. Furthermore, Intel currently does not include 1394 support in its PC peripheral chip sets. This situation means that in order to use a 1394 bus in an application, both the 1394 device and the 1394 controller must be acquired.
Other features make 1394 ideal for many types of instrument control applications. While devices must be within 4.5 m of the bus socket to conform to the specification, up to 16 devices can be daisy-chained together for a maximum run of 72 m. FireWire also features "hot pluggable" technology that enables devices to be connected and disconnected while the system is powered. However, there are few instruments with 1394 ports available.
Fig. 1. The GPIB connector and its signal assignments are shown. Ethernet
Instrument control applications over Ethernet take advantage of several characteristics of the bus, such as remote control of instruments, sharing among different users at different locations, and easier integration and publication of the resulting data. Moreover, users can take advantage of the already existing knowledge within their company on Ethernet-based networks.
Furthermore, instrument vendors have recently started to include Ethernet as an alternative communication interface on stand-alone instruments. Although Ethernet is somewhat new to instrument control applications, it is a mature technology that is widely used for measurement systems. With more than 100 million TCP/IP-capable computers worldwide, the shear ubiquity of Ethernet for controlling instruments is compelling.
Some factors to consider when deciding to use Ethernet for instrument control are transfer rate, determinism, and security. Most common Ethernet networks today are 10BaseT or 100BaseTX, transferring data at 10 Mbits/sec or 100 Mbits/sec, respectively. However, these transfer rates do not imply that your application achieves the same performance.
The nature of Ethernet — with its overhead, carrier sense, collision detection, and bus sharing by multiple devices — not only does not allow you to achieve the theoretical transfer rates, but it cannot be deterministic in assuring data transfer, depending on topology. In addition, if you have a very sensitive instrumentation system based on Ethernet, you need to take additional security measures to ensure its integrity (for example, firewalls).
Created in 1995, VXI is a standard for controlling instrumentation over Ethernet (see "Bus schedule" for explanations of acronyms). This protocol was created through the VXI plug and play consortium and defines GPIB-style communication over Ethernet. Some virtual instrument software architecture (VISA) software supports control of Ethernet-based instrumentation, and it is easy to use VXI-11 compatible instruments since you can reuse your VISA code written for other buses (GPIB, Serial, or VXI) virtually unchanged.
USB was primarily designed to connect peripheral devices, such as keyboards and mice, with PCs. The USB 1.1 specification has a maximum throughput of 12 Mbits/sec. However, future USB devices will have a throughput of 480 Mbits/sec, thanks to the USB 2.0 specification.
The USB host automatically detects when a new device has been added, queries the device for its identification, and configures the drivers appropriately. The topology of the bus allows up to 127 devices to run concurrently on one port.
USB ports also come standard on today's PCs, which means that you do not have to purchase a dedicated controller to interface to a USB-based device. The standard delivers an inexpensive, yet easy-to-use, connection between devices and PCs and provides a "step up" from conventional serial port technology. The setup features faster performance, "hot pluggable" functionality, built-in operating system configuration, and thin and flexible cabling, which allows you to connect multiple devices from the same port.
Although USB has many attractive benefits, there are some less convenient factors when comparing it to other buses. USB cables are not industrially graded, which can degrade the data in noisy environments; and there is no robust mechanism to prevent them from accidentally being detached. In addition, the USB system topology allows for a maximum distance of 30-m between the controller and the device, after using repeaters.
Finally, even though there is a great potential for USB instrumentation, especially with the April 2000 release of the USB 2.0 specification, currently there is no standard protocol available for controlling instruments over USB. In addition, there are few instruments with USB ports available.
Due to the slow shift of instrument manufacturers to implement new buses, bridge products are emerging as a viable solution. Bridge products allow you to convert from one bus type to another one. For example, one end of a bridge product may plug into an Ethernet, USB, or FireWire port in your computer or system, while the other end connects to traditional GPIB or Serial ports in your instruments .
With bridge products, you can take advantage of the plug-and-play capabilities, ease of use, and wide availability of controllers that practically come free with new computers, while building applications by conserving your investment in hardware, software, and time. Bridge products should be designed as a transparent solution for the application.
For example, you should be able to take the code written for a GPIB plug-in controller and reuse it without any modifications if you decide to replace the GPIB plug-in controller with an Ethernet-to-GPIB bridge product.
Bridge products solve the integration of legacy equipment into systems with new buses incorporated into the computer. However, in the future, systems will consist not only of legacy equipment, but also of new instrumentation equipment with new communication buses on them. Moreover, it is possible that more than one of the buses discussed here, or even some other bus, will be present in the same instrumentation system.
This scenario leaves engineers with the task of implementing mixed I/O systems. And the best way to design such systems is to base them on the appropriate software architecture capable of handling multiple buses without adding complexity to the equation. VISA has this capability.
Instrument control software
The virtual instrument software architecture (VISA) specification was created by the VXI plug-and-play Systems Alliance in 1993 to serve as a common application programming interface (API) to control VXI, GPIB, and Serial instruments (Fig. 3). VISA then became the preferred API used in the development of instrument drivers with thousands written in different development environments. With VISA, users could be more productive since they only needed to learn one API instead of three separate, very different ones.
Today, with the potential for new instrument control buses to be part of systems, there is an even higher demand for a common software API. Users could create code compatible with the traditional connectivity buses and upgrade their equipment to new control buses without having to modify their software. This situation helps preserve their hardware and software investments, while eliminating the learning curve of a different API. Currently, one implementation of the VISA specification supports GPIB, serial, and VXI interfaces, as well as Ethernet and Peripheral Component Interconnect eXtensions for Instrumentation, the latest, most popular connectivity options for instrumentation systems.
The new VISA design separates the support for connectivity buses from the core VISA library, which contains the popular high-level VISA API. With this model, each different bus requires a passport to connect to the core VISA engine. With this plug-in architecture, support for new buses can be added very easily without disturbing the existing interfaces.
Several buses, such as Ethernet, USB, and IEEE 1394, have great potential to be standard bus interfaces for test and measurement applications. As technology evolves, these and other buses, such as Bluetooth, will be considered for instrument control applications. On the other hand, equipment with traditional control buses will be present in instrumentation systems for many years to come.
The future of instrument control will be that of a mixed I/O world. The key relies on having a system with the adequate structure to leverage existing hardware and software investments, while at the same time incorporate and take advantage of the latest technologies.
Edited by Jack Smith, Senior Editor, 630-320-7147, email@example.com
Controller-in-charge — Although there can be several controllers on the GPIB, only one is the controller-in-charge (CIC). Active control can pass from the current CIC to an idle controller. Only the system controller can make itself the CIC.
GPIB signals and lines — Figure 1 is an illustration of a GPIB connector showing its signal assignments. The GPIB interface system consists of 16 signal lines and 8 ground-return or shield-drain lines. The 16 signal lines are grouped into 8 data lines, 3 handshake lines, and 5 interface management lines.
Data lines — The 8 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 signal — DIO8 — is either unused or used for parity.
Handshake lines —Three lines asynchronously control the transfer of message bytes among devices. The process, called a three-wire interlocked handshake, guarantees that message bytes on the data lines are sent and received without transmission error.
NRFD (Not ready for data)—This signal indicates when a device is ready or not ready to receive a message byte. All devices receiving commands, listeners receiving data messages, and the talker enabling the HS488 protocol drive this line.
NDAC (Not data accepted)—This signal indicates when a device has or has not accepted a message byte. All devices when receiving commands and listeners when receiving data messages drive this line.
DAV (Data valid)—This signal indicates when the signals on the data line are stable (valid) and can be accepted safely by devices. The controller drives DAV when sending commands, and the talker drives DAV when sending data messages.
Interface management lines—Five lines manage the flow of information across the interface.
ATN (Attention)—The controller drives the ATN line true when it uses the data lines to send commands, and drives ATN false when a talker can send data messages.
IFC (Interface clear)—The controller drives the IFC line to initialize the bus and become CIC.
REN (Remote enable)—The controller drives the REN line to place devices in remote or local program mode.
SRQ (Service request)—Any device can drive SRQ to asynchronously request service from the controller.
EOI (End or identify)—This signal has two purposes. The talker drives EOI to mark the end of a message string. The controller drives the EOI to tell devices to identify their response in a parallel poll.
Physical characteristics — Devices are usually connected with a shielded 24-conductor cable with both a plug and a receptacle connector at each end. Devices can be linked in a linear configuration, star configuration, or a combination of the two.
This "bus schedule" is a guide to the acronyms used within this article.
GPIB—General purpose interface bus
VXI—VME eXtensions for instrumentation
VME—VMEbus is a computer architecture. The term "VME" stands for VERSAmodule Eurocard and was first coined in 1980 by the group of manufacturers who defined it. This group was composed of people from Motorola, Mostek, and Signetics who were cooperating to define the standard. The term "bus" is a generic term describing a computer data path, hence the name VMEbus.
Actually, the origin of the term "VME" has never been formally defined. Other widely used definitions are VERSAbus-E, VERSAmodule Europe, and VERSAmodule European. However, the term "Eurocard" tends to fit better, as VMEbus was originally a combination of the VERSAbus electrical standard, and the Eurocard mechanical form factor.
PCI—Peripheral component interconnect is a high-performance plug-and-play expansion bus architecture originally developed by Intel to replace ISA and EISA. It has achieved widespread acceptance as a standard for PCs and workstations. It offers a theoretical maximum transfer rate of 132 Mbytes/sec.
PXI—PCI eXtensions instrumentation was designed as a different implementation of CompactPCI, which added the necessary features for instrumentation. The PXI specification defines how PC technology can successfully be applied to measurement and automation. By leveraging off of CompactPCI, Microsoft Windows, and VXI, the PXI specification brings together the right technologies for PC-based test and measurement, instrumentation, and industrial automation. Announced in August 1997 as an open specification, PXI has generated endorsements from numerous companies worldwide.
VISA—Virtual instrument software architecture
VXI—VME eXtensions for instrumentation was designed to improve the VME specification for instrumentation systems. Motorola and a number of other companies developed the VME standard in the late 1970s. It has been widely accepted as a backplane standard for many electronic platforms. It defines the electrical and mechanical backplane characteristics that allow a wide variety of companies to develop products to work in a mix-and-match fashion to develop electronics systems. Five leading test companies (Colorado Data Systems, Hewlett-Packard, Racal Instruments, Tektronix, and Wavetek), who formed the VXI Consortium felt there was a need for a standard that would enable anyone to develop instruments that would:
Be capable of handling demanding electronic test problems
Be open to all
Have interoperable modules (work together seamlessly)
Reduce the size of current instrumentation systems
Increase the speed of automatic test equipment (ATE) systems.
The VXIbus Specification was submitted and accepted by the IEEE Standards body in 1994.
What is Bluetooth?
Named after Harald Bluetooth, who was a fierce Viking king in 10th century Denmark, Bluetooth is a standard for wireless "connections" and communication developed by a consortium of electronics manufacturers. It allows electronic equipment, such as computers, cell phones, personal data assistants (PDAs), instruments, and control devices, to communicate and operate. Bluetooth is intended to be a standard that works on a physical standard, in that it uses radio frequency, and on a protocol standard.
Bluetooth technology seeks to eliminate cabling among electronic devices by creating an open industry standard for wireless communication. Ericsson, IBM, Intel, Nokia, and Toshiba created the Bluetooth Special Interest Group (SIG), which is responsible for driving this royalty-free, open-specification technology and bringing it to market.
Bluetooth technology is used for wireless communication of voice and data using a short-range radio. Bluetooth-enabled devices work with one another, regardless of their different functions. The Bluetooth radio is low-power and operates in the Industrial, Scientific, and Medical (ISM) Band at 2.4 GHz. Although a short-distance version operates within 10 m, a long-range version operates up to 100 m. To reduce interference from other devices, the Bluetooth specification uses spread-spectrum transmission with frequency hopping. The Bluetooth hops around 79 frequencies, 1600 times/sec. If interference causes a delay, then the data packet is retransmitted. In addition to specifying the physical RF layer, Bluetooth defines upper layer services, such as media access and discovery.
Because Bluetooth is wireless, it eliminates many issues associated with cabling and connectivity that can plague PC peripherals and handheld devices. Similarly, Bluetooth could provide convenient, wireless connectivity for measurement components. Today, there are many types of cabling and interfacing standards, such as PCMCIA, USB, serial, and more. While these cabling standards will continue to be a part of measurement and automation systems, the convenience and low cost of a Bluetooth connection can conceivably benefit a wide variety of measurement and automation applications.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.