Reasons why ibwrta might not cause an asynchronous callback

[Colin at Gould Nicolet]

I have been using asynchronous reads and writes in a C++ class in our application for several years on a PC platform with NI 488.2 version 1.7 installed. Recently we have found that installing NI 488.2 version 2 or later causes the application to respond to a single query but no more.

This is a similar area of the GPIB drivers that I questioned in a post in December last year regarding the non-return of ibnotify.

I have attached two SPY files which I will annotate below

'correct callback ...' shows the operation on a system with version 1.7

1 - 2 general initialisation of the application
3 - 8 the application initiates an asynchronous read and receives the "*IDN?" command. At this point
the application creates the response string
9 - 14 the application initiates an asynchronous write to return the string
15 - 17 the application prepares to read the next command
18 - the application shuts down.

'no callback ...' shows the operation on a system with version 2.1 installed.

1 - 2 general initialisation of the application
3 - 8 the application initiates an asynchronous read and receives the "*IDN?" command. At this point the application creates the response string
9 - 13 the application initiates an asynchronous write to return the string. At this point no callback occurs as it did under 1.7
14 - the application shuts down, this time experiencing some trouble in the process.

It should also be noted that the string does actually get back to the system that originally sent the *IDN? but because my C++ class did not get a callback it thinks it is still in the process of sending.

Can anyone give me some clues as to why the callback is not happening? As with
my previous post I am willing to believe that something in the way my C++ class handles the asynchronous reads and writes is incorrect but since the code has worked for some years with version 1.7 it must be something subtle.

[GPIB_Guru]

Can you right-click on your gpib-32.dll and tell me what version it says? I have done some testing and I have been unable to reproduce this problem. My code is pretty simple. The notify callback function simply releases the semaphore. I seem to be able to run this all day using NI-488.2 2.1. (This does not imply that something is wrong with your code, but somehow our two tests do not seem to get the same results. I hope we can find out the differences!)

Second note: Have you considered using NI-Device? NI-Device is designed for device-side applications and may make all of your problems go away. It is something to consider.

My Code (snippet):

FunctionName ()
{
// Open handle to GPIB 1, set pad and TMO
// so that I have time to manually talk to

// this device.
l_DeviceHandle = ibfind ("GPIB1");
ibrsc (l_DeviceHandle, 0);
ibpad (l_DeviceHandle, 3);
ibtmo (l_DeviceHandle, T300s);

// Loop a few times reading from the "controller"
// and sending back a response.
for (int i = 0; i < 3; i++)
{
ibrda (l_DeviceHandle, l_Buffer, 100);
ibnotify (
l_DeviceHandle,
TIMO | CMPL,
CallbackFunction,
NULL
);

WaitForSingleObject (
g_Semaphore,
0xFFFFFFFF
);

// Call ibwait to get updated global variables
ibwait (l_DeviceHandle, 0);
l_Buffer[ibcntl] = '\0';
printf ("Received Buffer = %s\n", l_Buffer);

ibwrta (
l_DeviceHandle,
"Got Buffer",
strlen ("Got Buffer")
);

ibnotify (
l_DeviceHandle,
TIMO | CMPL,
CallbackFunction,
NULL
);

WaitForSingleObject
(
g_Semaphore,
0xFFFFFFFF
);

}

ibonl (l_DeviceHandle, 0);
}

[Colin at Gould Nicolet]

Here's the details of the dll

c:\winnt\system32\gpib-32.dll
size 229,376 bytes
created 22 may 2003 15:01:20
modified 22 may 2003 15:01:20
version 2.1.0.3158
product name NI 488.2 for Windows
product version 02.01.00 158

Looking back at the two spy files I notice that the ibsta value is zero at the time of the write in the nocallback listing whereas it is 0x148 in the working spy file. I don't know whether that is significant.

By the way the working version is running on an NT system and the non-working version is on Windows 2000 in case that is relevant. However, the source code and the testing program is the same in both cases.

Unfortunately NI Device is not an alternative at this time due to time and finacial
constraints. For various reasons the only alternative I have is to re-work the existing code so that it works.

[Colin at Gould Nicolet]

More observations :-

In the non-working spy file entry 10 (asynchronous I/O resynchronised for ibrda()) has no equivalent in the working spy transcript. Is this relevant? Is it a coincidence that it it happens near the ibwrta?

According to the help on ibnotify "once the I/O is complete the application must resynchronise with the NI 488.2 driver" and it also says that a call to ibnotify with CMPL set in the ibsta value will do so. Both the call to ibnotify after the ibrda and after the ibwrta have such a flag.

Also in the ibnotify documentation there is a note that says that if ibnotify is called with the CMPL flag included and CMPL is already true, then the callback will be called immediately. As far as I can make out this is the sit
uation at step 8 of the non-working spy file and yet the callback is never executed.

[Colin at Gould Nicolet]

Sorry, in the last line of that comment I should have said

As far as I can make out this is the situation at step 12 of the non-working spy file and yet the callback is never executed

[Colin at Gould Nicolet]

Yet more observations :-

As well as CMPL I also pass the TIMO flag to ibnotify. If I leave the application running for the 1000 seconds specified in the timeout setting I do indeed get a call to the callback function with the TIMO flag set AND the CMPL flag set.

[Geneva L.]

We would like you to try the beta version for our next driver. You can sign up at http://www.ni.com/beta for GPIB Beta. At the end of registering, make sure you accept the Terms and Conditions.

Regards,
Geneva L.
National Instruments