Electrical computers and digital data processing systems: input/ – Intrasystem connection – Bus access regulation
Reexamination Certificate
2000-12-21
2003-10-14
Ray, Gopal C. (Department: 2181)
Electrical computers and digital data processing systems: input/
Intrasystem connection
Bus access regulation
C710S046000
Reexamination Certificate
active
06633937
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to GPIB instrumentation systems, and more particularly to a system and method for performing autopolling of GPIB instruments using heuristic information for improved efficiency.
DESCRIPTION OF THE RELATED ART
An instrument may be defined as a device which collects information from an environment and/or displays this information to a user. Examples of various types of instruments include oscilloscopes, digital multimeters, pressure sensors, etc. Types of information which might be collected by respective instruments include: voltage, resistance, distance, velocity, pressure, frequency of oscillation, humidity or temperature, among others.
The original GPIB was developed in the late 1960s by Hewlett-Packard (where it was called the HP-IB) to connect and control programmable instruments that Hewlett-Packard manufactured. With the introduction of digital controllers and programmable test equipment, the need arose for a standard, high-speed interface for communication between instruments and controllers from various vendors. In 1975, the Institute of Electrical and Electronic Engineers (IEEE) published ANSI/IEEE Standard 488-1975, IEEE Standard Digital Interface for Programmable Instrumentation, which contained the electrical, mechanical, and functional specifications of an interfacing system. The original IEEE 488-1975 was revised in 1978, primarily for editorial clarification and addendum. This bus is now used worldwide and is known by three names: General Purpose Interface Bus (GPIB), Hewlett-Packard Interface Bus (HP-IB), and IEEE 488 Bus.
The original ANSI IEEE 488 standard, now referred to as IEEE 488.1, was introduced in 1975 and greatly simplified the interconnection of programmable instruments by clearly defining mechanical, electrical and hardware protocol specifications. This enabled users to connect instruments from different manufacturers to a standard cable, thus allowing the instruments to communicate with each other. The original IEEE 488.1 standard dramatically improved the productivity of test engineers. However, this original standard included a number of limitations. More specifically, the IEEE 488.1 standard did not specify data formats, status reporting guidelines, a message exchange protocol, configuration commands, or a minimum set of device commands. As a result, different manufacturers implemented each item differently, resulting in integration problems for the test system developer.
In 1987, a new IEEE 488 standard for programmable instruments and devices was approved which strengthened the original IEEE 488.1 standard by precisely defining how controllers and instruments communicated with each other. The IEEE 488.2 standard kept the IEEE 488.1 standard completely intact while also defining standard data codes and formats, a status reporting model, a message exchange protocol, a set of common commands for all instruments, and controller requirements, therefore making systems more compatible and simplifying program development. In general, the IEEE 488.2 standard focuses on software protocol issues while the IEEE 488.1 standard is primarily hardware oriented.
Thus the IEEE 488 bus, also referred to as the General Purpose Instrumentation Bus (GPIB), is used for connecting instruments and controllers to a common bus to perform various test and measurement functions. The IEEE 488 Standard describes a standard interface for communication between instruments and controllers from various vendors. The IEEE 488.1 standard contains information about electrical, mechanical, and functional specifications. The GPIB is a digital, 8-bit parallel communications interface with data transfer rates of 1 Mbytes/s and above, using a 3-wire handshake. The bus supports one System Controller, usually a computer, and up to 14 additional instruments. The ANSI/IEEE Standard 488.2-1992 extends IEEE 488.1 by defining a bus communication protocol, a common set of data codes and formats, and a generic set of common device commands.
A typical GPIB system comprises one or more GPIB instruments, up to 14 instruments, and a controller, typically a GPIB interface board installed in a general purpose computer, connected by standard GPIB cables. A GPIB software application executes on the computer to control the instruments. The GPIB application interfaces through GPIB driver level software to the GPIB controller.
In response to the GPIB application, the controller provides program commands to the instruments, and the instruments return formatted data and response messages to the controller. GPIB instruments are message-based devices which are programmed with high-level ASCII character strings. A respective GPIB device includes a local processor that parses the command strings and sets the appropriate register bits to perform the indicated functions.
As noted above, a GPIB system includes GPIB driver level software which interfaces between a GPIB application and the GPIB hardware. The de facto standard for GPIB driver level software are the NI-488 and NI-488.2 software architectures, collectively referred to as the NI-488 software architecture, which is available in the NI-488 and NI-488.2 driver software products from National Instruments. The NI-488 software architecture includes an Application Programming Interface (API) which allows the GPIB application to call or invoke functions in the GPIB driver level software to communicate with the GPIB hardware. In other words, the GPIB driver level software handles the details of communication, i.e., the transfer of commands and data, over the GPIB connection between the computer and the GPIB instruments.
Autopolling
One function of a GPIB controller is to detect and respond to service requests from devices on the bus. The Service Request (SRQ) line on the GPIB is designed to signal the controller when a service request is pending. All devices share a single SRQ line. When a GPIB device asserts the SRQ line to request service, the controller must then determine which device is asserting the SRQ line and respond accordingly. The most common method for SRQ detection and servicing is the serial poll. Serial polling is a method of obtaining specific information from GPIB devices when they request service. When the controller serial polls the GPIB, the controller queries each device looking for the one that asserted SRQ. Each GPIB device responds to the poll by returning the value of its Status Byte. This Status Byte include one bit which indicates whether the device is asserting SRQ and 7 bits of other status information.
Some GPIB driver software programs, such as NI-488.2 driver software programs, have an internal feature called Automatic Serial Polling or Autopolling. If Autopolling is active and the SRQ line asserts, the driver will automatically 1) begin serial polling each device that has been opened by ibfind or ibdev, stopping when the SRQ line un-asserts; 2) store the serial poll response status byte(s) in a memory queue for later retrieval; and 3) set the RQS bit in the status word (ibsta) of each device that returned a status byte with Bit 6 set. The main advantage gained in using autopolling is that devices requesting service are polled as quickly as possible.
The controller may poll the eligible devices in any order it chooses. In prior art systems, the controller constructs a list of eligible devices in some arbitrary order. For example, the list of devices may be sorted in the order in which the controller was made aware of the devices. In another example, the list may be sorted by the GPIB address of the devices. During autopolling, the controller polls the devices in the listed order.
However, these approaches result in an arbitrary polling order, as mentioned above, and so the autopolling process may not poll the devices in an efficient manner. The polling stops when the controller locates the device asserting SRQ. Thus, the time required to complete a serial poll is related to the number of devices polled before SRQ unasserts. Therefore, improved systems and methods are desired f
Hood Jeffrey C.
Meyertons Hood Kivlin Kowert & Goetzel P.C.
National Instruments Corporation
Ray Gopal C.
LandOfFree
GPIB system and method which performs autopolling using... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with GPIB system and method which performs autopolling using..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and GPIB system and method which performs autopolling using... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3158607