National Instruments GPIB-PC User Manual

Page 71

GPIB-PC Functions — Overview

Section Four

GPIB-PC User Manual

4-10

©National Instruments Corp.

EFSO (12) EFSO results when an

IBRDF

IBWRTF

call encounters a

problem performing a file operation. Specifically, this error
indicates the function was unable to open, create, seek,
write, or close the file being accessed. The specific DOS
error code for this condition is contained in

IBCNT

EBUS (14) EBUS results when certain GPIB bus errors occur during

device-level calls. It is necessary in all device calls for the
handler to send command bytes to perform addressing,
serial polls, and to send other bus management information.
Devices are expected to accept these command bytes
within the time limit specified by the configuration program
or by

IBTMO

. EBUS occurs if a timeout occurred during

the sending of these command bytes. Under normal
operating circumstances, the remedy would be to find out
which GPIB device is accepting commands abnormally
slowly and fix the problem with that device. In situations
in which slow handshaking of the commands is desirable,
lengthen the time limit either with the configuration
program or the

IBTMO

function.

ESTB (15) ESTB occurs only during the

IBRSP

call. This indicates

that one or more serial poll status bytes which were
received due to automatic serial polls have been discarded
for lack of room to store them. Several older status bytes
are available; however, the oldest is being returned by the

IBRSP

call. If an occasional lost status byte is not

important in your application, you may consider this error
code informative only and ignore it. If your application
cannot tolerate missing even one status byte, the remedy is
to disable Automatic Serial Polling using

IBCONF

ESRQ (16) ESRQ occurs only during the

IBWAIT

call. This indicates

that a wait for RQS is not possible because the GPIB SRQ
line is stuck on. The usual reason for this situation is that
some device that the handler is unaware of is asserting
SRQ. Since the handler does not know of this device, it
will never be serially polled and SRQ will never go away.
Another reason for the situation would be that a GPIB bus
tester or similar equipment was forcing the SRQ line to be
asserted, or that there is a cable problem involving the
SRQ line. Although the occurrence of ESRQ signals a
definite GPIB problem, it will affect no GPIB operations
whatever except that the RQS bit cannot be depended on
while the condition lasts.