GPIB Error Codes and Common Solutions (Part 3) - KnowledgeBase - Support

1 ratings:

4 out of 5

Rate this Document

GPIB Error Codes and Common Solutions (Part 3)

Hardware: GPIB, GPIB>>Plug-in Controllers>>PCI-GPIB

Problem:
What is the solution to my GPIB error code

Solution:
Much of the following text is derived from the NI-488.2 User Manual for Windows (see the Related Link, below):

ELCK (21)

Error Condition:
GPIB interface is locked and cannot be accessed.
Possible Cause:
This error usually occurs when there are two or more processes that want to access the same interface and one process has already locked the interface. This error is returned when the operation cannot be performed because of the existing lock on the interface. It is also returned when a process tries to unlock an interface when no such lock exists.
Solutions:
The way to avoid the ELCK error is to wait for a random amount of time before trying to lock the interface again. In case you are using the iblck command to lock the interface, increase the LockWaitTime and wait for the other process to relinquish control over the interface. Also make sure that processes do not lock an interface up for the entire period of execution.

EARM (22)

Error Condition:
ibnotify callback failed to rearm.
Possible Cause:
This error occurs when we use asynchronous notification (ibnotify) in NI-488.2 applications. This function is useful if you want your application to be notified asynchronously about the occurrence of one or more GPIB events. This event notification is carried out by means of a callback function. The callback function is registered with the NI-488.2 driver when the ibnotify call is made. This error indicates that this callback notification failed to rearm itself by returning an illegal value or when a fatal driver error (EDVR) has occurred.
Solutions:

Ensure that the value being returned by your Callback function is a valid ibnotify mask value
Return a zero value from your Callback function to unregister the asynchronous event notification mechanism. Then call ibnotify to re-enable notification

EHDL(23)

Error Condition:
Input Handle is invalid.
Possible Cause:
Several GPIB commands take in the input handle of the board or the device as an input parameter which can be the source of this error. This error can occur under several circumstances. Some scenarios are listed below:

A valid board handle is passed in as a device handle parameter or vice versa
An invalid board or device descriptor is passed as input to any NI-488.2 function
A board id outside the range of 0-99 is passed in to a traditional NI-488.2 board-level function or NI-488.2 routine
ibconfig or ibmask is called with a device unit descriptor and a board-only configuration option, or with a board unit descriptor and a device-only configuration option

Solutions:

Check to see if the device-level and board-level functions are not mixed up when calling the respective functions
Also check if the board index passed to the NI 488.2 call is a valid index number

EWIP (26)

Error Condition:
Wait In progress on specified Input handle.
Possible Cause:
This error occurs in scenarios that have more than one thread in the same process and when two or more threads are accessing the same interface. EWIP indicates that an ibwait call is already in progress on the specified unit descriptor and it occurs when a thread is already performing an ibwait using the same descriptor and another thread tries to calls ibwait on the same descriptor.
Solutions:
Make sure that at any given point in time, only one thread is performing an ibwait call on the given unit descriptor.

ERST (27)

Error Condition:
Event Notification was cancelled due to a reset of the interface.
Possible Cause:
ERST results when an event notification was cancelled due to a reset of the interface. An ibwait call pending in the driver returns ERST in the following situations:

Another thread in the same process calls ibonl using the same unit descriptor as ibwait
Another thread or process issues a board-level ibonl 1

An ibnotify callback may be invoked with ERST in the following situations:

Another process issues a board-level ibonl 1

Solutions:

Do not call ibonl with ibwait calls still pending in the driver
Prevent other applications from calling ibonl by locking the interface with iblck

EPWR (28)

Error Condition:
The Interface lost power.
Possible Cause:
EPWR results when an interface loses power. This often results when the system goes to and returns from a standby state.
Solutions:

Take all handles offline and reinitialize the application
Quit the application and restart the system
Disable standby and hibernate modes on the PC

Report Date: 08/25/2004
Last Updated: 05/08/2008
Document ID: 3CO9NH3F

Your Feedback!

Poor | Excellent

Yes

Document Quality?

Answered Your Question?

Please Contact NI for all product and support inquiries.