how to cancel syncronous I/O DLL-call?

[RAMS_Anite]

We have an application with timeout set to 300seconds. If the application is terminated whilst a Send of Receive is in progress, the application is killed, but the NI driver remains active until the timeout is reached (and therefore blocks any further GPIB attempts).

Is there any way to cancel a syncronous I/O operation other than timeout?

Thanks.

[Randy Solomonson]

Hello-

Use ibln to detect a listener. GPIB function calls should never really timeout. It is possible to detect a GPIB listener before a transmission using the ibln command.

Randy Solomonson
Application Engineer
National Instruments

[RAMS_Anite]

Thanks for the reply. That is one possible solution, but our application wouldn't really suit this.

In short, we are stuck with 11 different forms of non-IEE488 compliant hardware and a legacy application which we have limited capability to change.

If we can't physically cancel a blocking driver, is possible to kill it somehow??

Are there any future releases of the NI DLL planned? If so, any chance of getting this raised as a change request?

Thanks,

Mat

[Randy Solomonson]

So ibln doesn't even work with these instruments? That sounds very unusual. What about ibrsp? Does it act the same way?

[RAMS_Anite]

It's not the case that ibln doesn't work with our instruments.

The reason we use a 300sec timeout is because we occasionally do a read from an instrument before the instrument is ready to respond (some instruments don't support SRQ or polling status byte). In which case, if we did a ibln prior to doing the receive, it'd fail, since it is currently processing and not listening to the bus. In these circumstances we do a receive and wait around for a while. Problem is that sometimes the response never arrives.

A lot of this is to do with the way we are programming the GPIB driver. We're using the low-level send/receives, so we can't set individual timeouts for each instrument. One instrument make take 4 minutes to respond, which is o
k, but another may take 30 seconds. If we don't receive a response after this period, we wish to abort the read.

It's a bit of a dodgy arrangement, but we are stuck with these instruments and their method of responding. What we are trying to achieve is a "controlled" failure, rather than the NI driver blocking for the full length of time.

[GPIB_Guru]

Have you tried to use the asynchronous calls, ibwrta and ibrda? These calls will not block. You can then poll for the call to be finished or you can even use an asynchronous callback (ibnotify) to have the driver inform you when the call is finished. If you wish to exit your program, you just need to cancel the I/O (i.e., ibstop) and cancel the notification (i.e., ibnotify 0).

[RAMS_Anite]

Ah yes, been there, done that!

Unfortunately our legacy application uses the low-level Send/Receive commands. Moving to the ibwrta and ibrda would require re-writing a large chunk of our driver, which we cannot do at present.

I've just spent 2 days on trying to do this, but had to stop due to the "can of worms" I had opened!

It'd be nice if ibstop worked on the sync calls!