Error Codes and Common Solutions

The NI-488.2M offers three global variables to keep track of the status of the GPIB. These global
variables are ibsta, iberr, and ibcntl.
ibsta is a 2-byte integer that indicates that status of the bus. This global variable is
updated after every NI-488.2M function call. The different bits are defined in the Win32
Function Reference Manual. If bit 15 is set (ibsta 0x8000), then an error occurred
during the last function call.
iberr indicates the nature of the GPIB error. This global variable only indicates an error
if bit 15 is set in ibsta.
ibcntl indicates the number of bytes that were successfully transferred during the last
I/O operation. It is also used to indicate what driver error occurred during an EDVR error.
Some errors occur more frequently than others. These common errors and their solutions are
listed here. Remember, errors are only valid if ibsta has the ERR bit (bit 15) set.
EDVR (0)
Error Condition: Operating System error.
Description: EDVR is returned when the board or device name passed to ibfind, or the board
index to ibdev, cannot be accessed. The global variable ibcntl contains an error code. This
error occurs when you try to access a board or device that is not installed or configured properly.
Possible Cause: Often EDVR errors are caused when you misspell the board name. For
example, you may type ibfind GPIB9 or ibfind GPIBo or ibfind GPIB 0
instead of ibfind GPIB0. If these dont solve the problem, make a note of the ibcntl
and contact National Instruments Technical Support.
Solutions:
Use ibdev to open a device without specifying its symbolic name.
Use only device or board names that are configured in the GPIB software configuration
utility as parameters to the ibfind function.
Use the GPIB Configuration utility to ensure that each board you want to access is
configured properly.
Use the unit descriptor returned from ibdev or ibfind as the first parameter in subsequent
NI-488 functions. Examine the variable before the failing function to make sure its value has
not been corrupted.
ECIC (1)
Error Condition: Function requires GPIB board to be Controller-In-Charge.
Description: ECIC is returned when one of the following board functions or routines is called
while the board is not CIC.
Any device-level NI-488 functions that affect the GPIB
Any board-level NI-488 functions that issue GPIB command bytes: ibcmd, ibcmda,
ibln, and ibrpp
ibcac and ibgts
Any of the NI-488.2 routines that issue GPIB command bytes: SendCmds, Ppoll,
Send, Receive, and FindLstn

Possible Cause: Often ECIC errors are caused when you do not send an interface clear at the
start of your program.
Solutions:
Use ibsic or SendIFC to make the GPIB board become CIC on the GPIB
Use ibrsc 1 to make sure your GPIB board is configured as System Controller
In multiple CIC situations, always be certain that the CIC bit appears in the status word,
ibsta, before attempting these calls. If it does not appear, you can perform an ibwait (for
CIC) call to delay further processing until control is passed to the board.
ENOL (2)
Error Condition: Function detected no Listeners.
Description: ENOL usually occurs when a write operation is attempted with no Listeners
addressed. For a device write, ENOL indicates that the GPIB address you are attempting to
communicate with does not mach the GPIB address of the device connected to the bus.
Possible Cause: The instrument you are trying to communicate with is not at the expected
primary address or the cable to the instrument is either disconnected or broken.
Solutions:
Make sure that the GPIB address of your device matches the GPIB address of the device to
which you want to write data.
Use the appropriate hex code in ibcmd to address your device.
Verify the cables are properly connected to the instruments. Possibly switch cables to verify
that the cable is not broken.
Make sure that at least two-thirds of your devices are powered on.
Call ibpad (or ibsad, if necessary) to match the configured address to the device switch
settings.
EADR (3)
Error Condition: GPIB board (GPIB0 or GPIB1) is not addressed correctly.
Description: EADR occurs when the GPIB board is CIC and is not properly addressing itself
before read and write functions. EADR is also returned by the function ibgts when the
shadow-handshake feature is requested and the GPIB ATN line is already unasserted. In this
case, the shadow handshake is not possible and the error is returned to notify you of that fact.
Possible Cause: Your GPIB board is configured for the same Primary address as the instrument
with which you are trying to communicate.
Solutions:
Never configure your GPIB board to the same address as your device. You should (almost)
always leave your GPIB board configured for Primary address 0 and no Secondary address.
Call ibpad 0and ibsad 0 at the beginning of your program to properly configure
your boards address.
Make sure that the GPIB board is addressed correctly before calling ibrd, ibwrt,
RcvRespMsg, or SendDataBytes.
Avoid calling ibgts except immediately after an ibcmd call. (ibcmd causes ATN to be
asserted.)

EARG (4)
Error Condition: Invalid argument to function call.
Description: EARG results when an invalid argument is passed to a function call.
Possible Cause: The following are some examples:
ibtmo called with a value not in the range 0 through 17
ibeos called with meaningless bits set in the high byte of the second parameter
ibpad or ibsad called with invalid addresses
ibppc called with invalid parallel poll configurations
A board-level NI-488 call made with a valid device descriptor, or a device-level NI-488
call made with a board descriptor
An NI-488.2 routine called with an invalid address
PPollConfig called with an invalid data line or sense bit.
Solutions:
Make sure that the parameters passed to the NI-488 function or NI-488.2 routine are valid.
Do not use a device descriptor in a board function or vice-versa.
ESAC (5)
Error Condition: GPIB board not System Controller as required.
Description: ESAC results when ibsic, ibsre, SendIFC, or EnableRemote is called
when the GPIB board does not have System Controller Capability.
Possible Cause: The GPIB board is not configured to be the System controller.
Solutions:
Give the GPIB board System Controller capability by calling ibrsc 1 or by using the
GPIB configuration utility to configure that capability into the software.
EABO (6)
Error Condition: I/O operation aborted.
Description: EABO indicates that an I/O operation has been canceled, usually due to a timeout
condition. Other causes are calling ibstop or receiving the Device Clear message from the CIC
while performing an I/O operation. Frequently, the I/O is not progressing (the Listener is not
continuing to handshake or the Talker has stopped talking), or the byte counted in the call which
timed out was more than the other device was expecting.
Possible Cause: The most source of EABO errors is during a Read. This happens on a read
because you tried to read from an instrument, but it did not have anything to say. There are a few
reasons why the instrument may not have anything to say:
The query to the instrument may have been misspelled. Possibly *IND? was send
when *IDN? is what the instrument was expecting. Because *IND? is an
unknown command, the instrument did not generate any data to send.
The query to the instrument may contain a command that the instrument does not
understand. Possibly your command (i.e., *IDN?) is not valid for this instrument.
The instrument is expecting a particular EOS character. For example, ID? will not
work, but ID?\n will.
The instrument does not send the EOI line with the end of transfer.
Solutions:

Use the correct byte count in input functions or have the Talker use the END message to
signify the end of the transfer.
Lengthen the timeout period for I/O operations using ibtmo.
Make sure you have configured your device to send data before you request data.
Verify that you have sent the appropriate data to the instrument.
If you receive all of the data and get and EABO error, look for a particular end of string
character (i.e., linefeed or carriage return) and configure the GPIB board to terminate the
read on that character using the ibeos function.
Verify the instruments command set by looking in the user manual for the instrument.

ENEB (7)
Error Condition: Nonexistent GPIB board.
Description: ENEB occurs when no GPIB board exists at the I/O address specified in the
configuration program. This problem happens when the board is not physically plugged into the
system, the I/O address specified during configuration does not mach the actual board setting, or
there is a system conflict with the base I/O address.
Solution:
Make sure there is a GPIB board in your computer that is properly configured both in
hardware and in software using a valid base I/O address.
EDMA (8)
Error Condition: Error occurs while using DMA for data transfers.
Description: EDMA occurs if a system DMA error is encountered when the NI-488.2M software
attempts to transfer data over the GPIB using DMA.
Solutions:
You can correct the EDMA problem in hardware by using the GPIB configuration utility to
reconfigure the hardware to not use a DMA resource.
You can correct the EDMA problem in software by using ibdma to disable DMA.
EOIP (10)
Error Condition: Function not allowed while asynchronous I/O is in progress.
Description: EOIP occurs when an asynchronous I/O operation has not finished before some
other call is made. During asynchronous I/O, you can only use ibstop, ibnotify, ibwait,
and ibonl or perform some other non-GPIB operations. If any other call is attempted, EOIP is
returned.
Possible Cause: Calling any non-supported GPIB function calls during asynchronous I/O.
Solution:
Resynchronize the driver and application before making further GPIB calls.
Resynchronization is accomplished using one of the following functions:
ibnotify If the ibsta value passed to the ibnotify callback contains CMPL,
the driver and application are resynchronized.
ibwait
If the returned ibsta contains CMPL then the driver and application are
resynchronized.
ibstop
The I/O is canceled; the driver and application are resynchronized.

ibonl
are

The I/O is canceled and the interface is reset; the driver and application
resynchronized.

ECAP (11)
Error Condition: No capability for operation.
Description: ECAP results when your GPIB board lacks the ability to carry out an operation or
when a particular capability has been disabled in the software and a call is made that requires
that capability.
Solution:
Check the validity of the call, or make sure your GPIB interface board and driver has the
needed capability
EFSO (12)
Error Condition: File system error.
Description: EFSO results when an ibrdf or ibwrtf call encounters a problem performing a
file operation. Specifically, this error indicates that the function is unable to open, create, seek,
write, or close the file being accessed. The specific operating system error code for this condition
is contained in ibcntl.
Solutions:
Make sure the filename, path, and driver that you specified are correct
Make sure that the access mode of the file is correct
Make sure there is enough room on the disk to hold the file
EBUS (14)
Error Condition: Command byte transfer error.
Description: EBUS results when certain GPIB bus errors occur during device functions. All
device functions send command bytes to perform addressing and other bus management
operations. Devices are expected to accept these command bytes within the time limit specified
by the default configuration or the ibtmo function. EBUS results if a timeout occurred while
sending these command bytes.
Possible Cause: There are no GPIB devices attached to your GPIB controller. This can be
because:
All of you instruments are turned off
One of your instruments is in error and is asserting a handshaking line
Your GPIB cable is disconnected
Your GPIB cable is broken
Solutions:
Verify that all instruments are operating correctly.
Disconnect all instruments and connect them one at a time to determine if one instrument is
causing the problem.
Check for loose or faulty cabling or several powered-off instruments on the GPIB.
If the timeout period is too short for the driver to send command bytes, increase the timeout
period.

ESTB (15)
Error Condition: Serial poll status byte(s) lost.
Description: ESTB is reported only by the ibrsp function. ESTB indicates that one or more
serial poll status bytes received from automatic serial polls have been discarded because of a lack
of storage space. Several older status bytes are available; however, the oldest is being returned by
the ibrsp call.
Possible Cause: Instrument is repeatedly asserting the SRQ line.
Solutions:
Call ibrsp more frequently to empty the queue.
Disable autopolling with the ibconfig function (option IbcAUTOPOLL) or the GPIB
configuration utility.
ESRQ (16)
Error Condition: SRQ stuck in the ON position.
Description: ESRQ can only be returned by a device-level ibwait call with RSQ set in the
mask. ESRQ indicates that a wait for RQS is not possible because the GPIB SRQ line is stuck
on.
Possible Cause: This situation can be caused by the following events:
A cable problem might exist involving the SRQ line.
A device unknown to the software is asserting SRQ. Because the software does not
know of this device, it can never serial poll the device and unassert SRQ.
A GPIB bus tester or similar equipment might be forcing the SRQ line to be asserted.
Solutions:
Check to see if other devices not used by your application are asserting SRQ. Disconnect
them from the GPIB if necessary.
Inspect the GPIB cables to see that the devices are attached and that the connectors are seated
properly.
ETAB (20)
Error condition: Table problem.
Description: ETAB occurs only during the FindLstn and FindRQS functions. ETAB
indicates that there was some problem with a table used by these functions.
Possible Cause:
In the case of FindLstn, ETAB means that the given table did not have enough room to
hold all of the addresses of the Listeners found
In the case of FindRQS, ETAB means that none of the devices in the given table were
requesting service.
Solutions:
In the case of FindLstn, increase the size of the result arrays.
In the case of FindRQS, check to see if other devices not used by your application are
asserting SRQ. Disconnect them from the GPIB, if necessary.