Serial polling is a method of obtaining specific information from GPIB devices when they request service. When you conduct a serial poll, the Controller queries each device looking for the one that asserted SRQ. The device responds to the poll by returning the value of its Status Byte. Device-dependent conditions, such as the presence of available data or an error condition, determine this value. ANSI/IEEE Standard 488.1-1987 specifies only one bit in the Status Byte, Bit 6, which is TRUE if the device requests service. The other bits in the Status Byte are left to the instrument manufacturer to define. IEEE 488.1-compatible instruments have bits that determine if an instrument error has occurred or if the device is conducting a self-test. These bit definitions are not consistent among instrument vendors and the method for determining the cause of a service request varies with each device.
ANSI/IEEE Standard 488.2-1987 solves this problem by defining certain service request conditions so that one model describes the Status Byte for all compliant devices. Bit 6, the device Request Service (RQS) bit, maintains the IEEE 488.1 definition. If Bit 6 is set, then the device requested service. The IEEE 488.2 standard defines Bits 4 and 5; instrument manufacturers define the remaining bits (0 through 3 and 7). Bit 4 is the Message Available (MAV) bit. This bit is set if the device has been previously queried for data and the device has a pending data message to send. Bit 5 is the Event Status Bit (ESB). This bit is set if one or more of the enabled IEEE 488.2-defined events occurs. These events include Power-On, User Request, Command Error, Execution Error, Device Dependent Error, Query Error, Request Control, and Operation Complete. The device can assert SRQ when ESB or MAV are set, or when a manufacturer-defined condition occurs.
The NI-488.2 routines are based on those sequences found in the IEEE 488.2 standard. Routines pertinent to SRQ servicing and serial polling are AllSpoll, FindRQS, ReadStatusByte, TestSRQ, and WaitSRQ.
AllSpoll can serial poll multiple devices with a single routine call. AllSpoll places the status byte from each instrument polled into a predefined array. You must manually check the RQS bit in the Status Byte of each device to determine whether that device requested service.
FindRQS can serial poll several devices. If one of the devices requests service by asserting SRQ, the routine returns the index and Status Byte value of the device requesting service.
ReadStatusByte returns the value of the Status Byte from a single device – that is, it performs a single serial poll. The program must manually check the RQS bit in the Status Byte value to determine whether that device requested service.
TestSRQ determines whether the SRQ line is asserted or unasserted.
WaitSRQ is similar to TestSRQ, except that WaitSRQ suspends the application program until either SRQ is asserted or the timeout is exceeded.
The following QuickBASIC example performs SRQ servicing and then uses NI-488.2 routines to determine which device requested service. In the following example, these assumptions are made: three devices are present on the GPIB at addresses 3, 4, and 5, and the GPIB interface is designated as bus index 0.
REM $include: 'qbdecl.bas'
REM SRQ servicing program using NI-488.2 routines. This code REM waits indefinitely in a loop for SRQ to be asserted. When REM SRQ is asserted, the program jumps to a user-defined REM subroutine which might serial poll the devices and analyze REM the serial poll status byte.
.
. board% = 0
100 CALL TestSRQ(board%, result%) IF result% = 1 THEN
CALL serial.poll ELSE
GOTO 100 END IF
Alternatively, you can implement the WaitSRQ routine to perform the same task, as shown in the following example. The main difference is that operations are suspended until SRQ is asserted, or the timeout limit is exceeded.
CALL WaitSRQ(board%, result%) IF result% = 1 THEN
CALL serial.poll ELSE
PRINT "WaitSRQ timed out; no SRQ" END IF
Once the GPIB Controller detects the SRQ line using one of the NI-488.2 routines, the next step is to serial poll each device. The serial poll status byte returned by each device provides valuable status information, such as whether the device requested service and why. The Controller can analyze the serial poll status byte retrieved from each device to obtain this information.
You can use the FindRQS routine to determine which device requested service. FindRQS serial polls each device and returns only the status byte of the device that requested service. The routine automatically checks for the RQS bit in each serial poll status byte. The index of the device that requested service, as listed in the address array, is returned in the ibcnt global variable. In the following example, assume that three devices at addresses 3, 4, and 5 are connected to the GPIB, and that one of them has asserted SRQ.
REM $include: 'qbdecl.bas'
DIM addresslist%(3) .
. addresslist% (0) = 3 addresslist% (1) = 4 addresslist% (2) = 5 addresslist% (3) = NOADDR
CALL FindRQS (0, addresslist% (), result%)
PRINT "Device at index";ibcnt;"requested service"
REM Analyze result% to determine why the device asserted SRQ. REM Refer to the documentation provided with your devices for REM more information on the serial poll status byte definitions.
You can use AllSpoll or ReadStatusByte to serial poll a device. The following code shows a possible implementation of AllSpoll. Assume that three devices at addresses 3, 4, 5 are present on the GPIB and SRQ is detected by the Controller. The serial poll status bytes for each device are stored in the array resultlist%() for further analysis.
REM $include: 'qbdecl.bas'
DIM resultlist% (2) .
.
CALL AllSpoll (0, addresslist% (), resultlist% ())
FOR i% = 0 to 2
IF resultlist% (i%) AND &H40 THEN
PRINT "The device at index";i%;"requested service" END IF
NEXT i%
The NI-488 functions are an industry standard for instrument control applications. The functions required to detect SRQ and to conduct a serial poll are described in this section.
NI-488 functions are divided into two groups, device functions and board functions. Device functions perform the addressing of a device and the data transfer in a single call. In comparison, one board function might address the devices on the GPIB board and another might actually perform the data transfer. Whether a function is designated as a board or device function depends on the unit descriptor value passed as one of the parameters in the function. If the unit descriptor refers to an interface board, the function is designated as a board function.
The NI-488 function used for serial polls is ibrsp. ibrsp conducts a single serial poll and returns the serial poll response byte to the application program. It is analogous to the NI-488.2 ReadStatusByte routine previously described.
The NI-488.2 drivers have an internal feature called Automatic Serial Polling or Autopolling. If Autopolling is active and the SRQ line goes high, the driver will automatically do the following: 1) begin serial polling each device that has been opened by ibfind or ibdev, stopping when the SRQ line goes low; 2) store the serial poll response status byte(s) in a memory queue for later retrieval; 3) set the RQS bit in the status word (ibsta) of each device that returned a status byte with Bit 6 set.
To be active, Autopolling must be enabled and allowed. Whether Autopolling is enabled is determined by the driver configuration program or by the ibconfig function. Note that all NI drivers are shipped with Autopolling enabled by default by the driver configuration program. Autopolling is allowed following the execution of any NI-488 device-level function. Autopolling is disallowed following the execution of any NI-488 board-level function or NI-488.2 routine.
If the GPIB board has an interrupt assigned to it, Autopolling can respond to the SRQ line immediately, as long as GPIB I/O is not in progress. If the board does not have an interrupt, Autopolling can respond to a service request only during a device ibwait for RQS or directly after a device function has completed and is about to return to the application program.
The main advantage gained in using Autopolling is that devices requesting service are polled as quickly as possible. If the GPIB board has an interrupt assigned to it, Autopolling is an interrupt service routine that guarantees the quickest response to the SRQ line being set. The disadvantage incurred in using Autopolling is that you must be careful in programming your applications so as to ensure that Autopolling is active (enabled and allowed).
From a programming standpoint, Autopolling is best suited for situations where only one device at a time will be requesting service. This stems from the fact that monitoring the SRQ line as an indication of a service request is not reliable when Autopolling is active. Thus, to check for a service request when Autopolling is active, you must check the RQS bit in the ibsta status word of every device that may be needing service. If Autopolling is not active, service requests are monitored by checking the SRQ line, which can be accomplished by simply checking the SRQI bit of any ibsta or by using iblines.
The following code illustrates the use of the ibwait and ibrsp functions in a typical SRQ servicing situation when Automatic Serial Polling is disabled. ibwait suspends program execution until certain conditions on the GPIB are met.
REM $include: 'qbdecl.bas'
REM For this example, assume that two devices are connected REM to the GPIB. Either device has the ability to assert SRQ. REM One of the devices is an oscilloscope (referred to as scope) REM and the other is a digital multimeter (referred to as dmm).
REM The first task is to wait for the SRQ line to assert. This REM can be done by an ibwait for SRQI or by a looping structure REM using ibwait 0 or iblines function. For this illustration, REM we use the ibwait function to wait for either the SRQI bit to REM be set or a timeout.
CALL ibfind ("gpib0", brd0%) CALL ibfind ("dev1", scope%) CALL ibfind ("dev2", dmm%)
CALL ibwait (brd0%, SRQI|TIMO)
REM If ibwait terminated because of SRQI being set, poll the REM devices and interpret returned status bytes to see which, if REM not both, requested service.
IF (ibsta% AND SRQI) THEN
REM In this case, because Autopolling is not active, ibrsp REM uses the gpib bus to get the status byte from the scope. CALL ibrsp(scope%, spr.scope%) IF (spr.scope% AND &H40) THEN PRINT "Scope asserted SRQ."
REM Here you would analyze the serial poll status byte, REM spr.scope%, to determine the cause of the SRQ.
CALL ibrsp(dmm%, spr.meter%)
IF (spr.meter% AND &H40) THEN PRINT "DMM asserted SRQ."
REM Analyze the rest of the serial poll status byte, REM spr.meter%, to determine the cause of the SRQ.
END IF
If Autopolling is active, the RQS bit of ibsta for the device in question must be used to determine if the device has requested service. Note that ibrsp is again used to return the Status Byte, but this time we already know Bit 6 is set because the RQS bit is checked on a single device basis. Furthermore, ibrsp only accesses the Status Byte that was obtained and stored previously by the Autopolling routine.
REM When Autopolling is active, the following code excerpt can be REM used as a subroutine to check if a particular device is REM requesting service.
SUB RQScheck(device%)
CALL ibwait (device%, 0) IF (ibsta% AND RQS) THEN
PRINT "Device asserted SRQ."
REM In this case, ibrsp does not poll the device but REM simply returns the response byte from memory. REM The status byte will be used to determine how to REM service the device.
CALL ibrsp (device%, spr.device%)
END IF
END SUB
This document describes how the GPIB Controller uses the NI-488.2 software to detect and respond to service requests from IEEE 488 devices on the bus. By implementing the NI-488.2 routines and NI-488 functions described in this document, you can conduct SRQ servicing and serial polling. The code examples demonstrate how you can use the routines and functions in the context of an application program.