I am using Windows NT 4 SP 6 on both the computer with NI-Device 1.1 (the "local" computer) and the computer with gpib-32.dll version 1.41.7649 (the "remote" computer). We wish to perform data acquisitions on the local computer and notify the remote when the acquisition is complete. I'm using ibnotify() with the board descriptor, SRQI mask, a callback function, and NULL for the RefData pointer. I've been testing with the application on the remote running in debug mode under Visual C++ 6 SP 5 and the application on the local machine in release mode.
Many messages are sent to the local to set up the acquistion, followed by the command to start the acquisition. The remote machine does nothing more at that point. The local machine performs the acquisition and upon completion, sends out an SRQ. The acquisitions are fairly rapid, maybe 10 to a second, and this notification method works for a short time, on the order of 1 minute. Inevitably, the process stops. The TRACE statements on the remote show that the callback function is not called. However, the application is frozen and cannot be closed, neither by the debugger, nor the task manager. I have to reboot the remote computer to continue. Sometimes, the crash is the BSOD.
This process is much more stable if I run the local application under the debugger, still in release mode but with messages being printed out. Alternatively, it is much more stable without the debugger if I put a 10th of a second delay before sending out an SRQ. The functions used on the local machine are UpdateStatusByte() and RequestService(). Throughout my testing, the eStatusMessage is always NIDEVICE_STATUS_SUCCESS for both functions. On the remote machine, the ibsta value returned from ibnotify is first 0x2164 followed by 0x168 after that. And iberr returned to the callback function is always 0.
We're wondering if we can make the process stable without using a delay. It's doubtful that the delay is completely stable and would always work regardless of the speed of the machines.
