Is there anyway to reset the GPIB driver during program execution?

[JustinR123]

Is there anyway to reset the GPIB driver during program execution?

[NI-488.2 master]

What exactly are you looking to do? If you take all of your board and device handles offline using ibonl(ud, 0), this will in essence "reset" the driver.

[JustinR123]

The issue at hand is that a thread is executing a series of tests which may or may not be making GPIB calls at any given time. The thread may be killed at any time with the function CmtTerminateThreadPoolThread (due to the user pressing the stop button on the GUI). Cooperative thread termination is not an option since a test may cause the thread of execution to lock up the system. The problem is that there may be outstanding GPIB calls at the time that the thread is stopped. These calls time out and generate run-time errors usually via the GPIB function ibrd. The motivation is to completely stop the GPIB driver while the thread is being killed, after which it can be re-initialized. Ideally.

[NI-488.2 master]

In a situation like this, you should prefer to use NI-488.2 asynchronous IO calls, such as ibrda or ibwrta. Then when the user hits the stop button, you can call ibstop, or just ibonl(ud, 0) and the driver will handle the cleanup of the asynchronous IO.

[JustinR123]

Calls such as ibrd and ibwrt tend to reside in NI device libraries such as the Tektronix TDS460/420 library tktds4xx.c. Is it safe to alter these libraries, replacing IO calls with their asyncronous counterparts?

[NI-488.2 master]

You should be able to do this somewhat easily. Essentially, the ibrd call can be substituted as follows:

ibrd(ud, buf, count);

is pretty much equivalent to

ibrda(ud,buf, count);
ibwait(ud, TIMO | CMPL);

You might need to add functionality to the instrument driver to take the handles offline, though a similar functionality may already exist.


Refer to the NI-488.2 Online Help for more details about these calls.

[JustinR123]

Is there a way to supercede all synchronous GPIB calls including the one that is currently executing? At this time it is not feasible for us to change the underlying GPIB calls to asynchronous calls.