Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

ibwait() and ibonl()

If one thread is waiting in a call to ibwait() on an interface's ud, and another thread calls ibonl() to put the same ud offline, what happens to the waiter?

The wait condition might be something like CMPL | ERR | TIMO, or it might be LACS | TIMO, or it might simply be LACS (depending on the application's needs).

Depending on the driver version and depending on the wait condition ibstop() might be safe to perform before ibonl(), but depending on the wait condition ibstop() might not even be meaningful in the first place. The application might find a need to close the device. Will waiting threads get a return from ibwait() or is there a possibility of hang (or worse)?
0 Kudos
Message 1 of 3
(3,166 Views)
I know for sure what the behavior is in the 2.1 driver. The ibwait call will return with the ERR bit set in ibsta. iberr will contain ERST(27), indicating that the event notification was cancelled due to a reset of the interface. I believe that this is also the case with the 2.0 driver, but I may be wrong. I really don't know what the behavior of the 1.7 driver is. It should be safe for you to do this with the 2.1 driver.
Message 2 of 3
(3,166 Views)
Thank you. It is a relief to know that if a situation arises where some threads don't know the status of other threads and only know that the user might be trying to recover from an error, it will be safe to call ibonl().

We have told our immediate customer that National Instruments strongly recommends upgrading to 2.1, and we think they will forward the message to their customer. We also gave them detailed instructions on how to get the download from National Instruments' web site.
0 Kudos
Message 3 of 3
(3,166 Views)