ibstop() doesn't abort ibrda() under Windows 98? (corrected question)

[ndiamond]

Is there a known problem in which a call to ibstop() doesn't abort a call to ibrda() in a non-controller under Windows 98?

If I make the controller send another byte to the non-controller then ibrda() completes normally and then ibstop() completes normally. But if I don't add that unwanted operation to the controller, then the non-controller seems to hang in both ibrda() and ibstop().

The problem seems to be reproduceable if the timeout is set to 0 (TNONE, i.e. infinite). ibrda() does not get stopped and the interface ud does not seem to become usable for other operations. But if I make the controller send another byte after that, the controller's send succeeds and the non-controller's ibw
ait() succeeds.

(In the original version of this question, I mistakenly said that the timeout of 10 seconds had no effect. I was experimenting both with and without timeouts and confused myself over which experiments had which problems. Sorry.)

[NI-488.2 master]

This is a known issue for the 1.7 version of the NI-488.2 driver. I'm not certain if this is still an issue with the current 2.1 driver. Which driver version are you using? Also, what type of GPIB interface are you using in this situation? Are you calling ibstop immediately after the ibrda?

The timeout value should not have any effect for asynchronous calls, except when trying to resynchronize with ibwait(TIMO|CMPL). In that situation, ibwait will wait the length of the timeout period until IO completes. If ibsta contains TIMO, then you could then use ibstop to abort the IO. It is generally recommended that you first try to resynchronize the IO with ibwait.

[ndiamond]

First the simple, original issue:

> This is a known issue for the 1.7 version of the
> NI-488.2 driver.

I originally installed 1.7 but upgraded to 2.0. I think I do not have liberty to experiment with 2.1 at the present time, but might experiment without approval after the end of the contract that I'm working on now.

> Also, what type of GPIB interface are you using in
> this situation?

On the non-controller for which I am developing an application, the interface is PCI-GPIB. (On the "controller" running ibic not the production controller application, the interface is GPIB-USB-B. I have not tried to track down bugs on that one.)

> Are you calling ibstop immediately after the
> ibrda?

Manually watching the operation of the non-contro
ller application, if it doesn't behave as expected, I try to make it stop. I might react faster than 10 seconds but surely at least a few seconds.

> The timeout value should not have any effect
> for asynchronous calls

I was not aware of that. Fortunately my programming already conformed to the rest of your recommendation. At first it didn't, because when ibwait reported TIMO I thought that the I/O already aborted, but trial and error revealed the need to call ibstop at that time. The information in your second paragraph really needs to be added to the published documentation.

[NI-488.2 master]

I have an idea of what could possibly be happening. Are you resynchronizing the IO from the same thread that you called ibrda in? If not, the 2.0 and 1.7 drivers will for sure hang during ibstop. You indicated that the ibrda call hung. The ibrda call should set up the IO and return immediately. Do you really just mean that ibrda is hung because the IO does not get stopped?

Perhaps you could attach an NI-Spy log of the problem so that I could have a better idea of what is happening here.


"I was not aware of that. Fortunately my programming already conformed to the rest of your recommendation. At first it didn't, because when ibwait reported TIMO I thought that the I/O already aborted, but trial and error revealed the need t
o call ibstop at that time. The information in your second paragraph really needs to be added to the published documentation."

Actually, this information is in the documentation for ibtmo:

"ibtmo sets the timeout period of the board or device to v. The timeout period is used to select the maximum duration allowed for a synchronous I/O operation (for example, ibrd and ibwrt) or for an ibwait or ibnotify operation with TIMO in the wait mask. If the operation does not complete before the timeout period elapses, the operation is aborted and TIMO is returned in ibsta. The timeout values represent the minimum timeout period. The actual period could be longer."

[ndiamond]

First, to continue the current thread: I guess that the hang was actually in ibwait() rather than in ibrda(). But indeed yes the I/O does not get stopped, and the pseudo-application (a small one for development and debugging) misbehaved a bit too much to guess a single point of hanging.

Now you add that if ibstop() is called from a different thread than the call to ibrda() then ibstop() will hang in 2.0 and 1.7. In some cases I call ibstop() from the callback routine, which is indeed a different thread from the thread that called ibrda(). I think this mandates an upgrade to 2.1, and hope that we can make a sufficiently strong recommendation to all of the parties involved in this.

Regarding the documentation for ibtmo() which you showed me, I still wish it would be added to other discussions of reads and writes in 321038g (NI-488.2 Function Reference Manual for Windows) and 321819e (NI-488.2 User Manual for Windows). Also if the documentation of ibrda() and ibwrta() would have a one-sentence addition (e.g. "the I/O operation started by this function is not subject to timeouts") it would be a kindness.

Second, a disaster: Today we demonstrated some developments to a customer. The customer is running Windows 2000. The customer had been running 1.7 but we upgraded to 2.0. In a situation where I had called ibrda() and then ibwait() with TIMO, and the timeout occured, it seems that my code was too quick in calling ibstop() and another ibrda(). The result was a BLUE SCREEN. This was repeatable. When doing the same operations in ibic, my typing was slow enough so it performed properly. The blue screen didn't name a suspected driver, but surely even if an application is defective it can't accomplish this without help from a defective driver. I think we have some pretty strong evidence to recommend an upgrade to driver 2.1.

Back in our own office with Windows 98, no blue screen in this situation. I'm wondering if my code should Sleep(100) between the return from ibwait() and the call to ibstop(). (Of course when there's no error flag then I don't call ibstop() and the next call to ibrda() seems OK.)

[GPIB_Guru]

Just out of curiousity, what programming language are you using?

While NI-488.2 works to create a non-controller, its primary use is as a controller. National Instruments has a product NI-Device that is designed to create non-controller GPIB applications. NI-Device currently supports C++.

[NI-488.2 master]

I would first suggest trying the 2.1 driver, as it did fix a few issues from the 2.0 release. If you do still find a blue screen with the 2.1 driver, we would like to know about it so that it can be fixed. I don't belive that you can call ibstop from an ibnotify callback with the 2.0 driver. However, you should definitely be able to do that with the 2.1 driver.

Why is your customer reluctant to upgrade to the 2.1 driver? I could understand if they have a large number of systems and it would be difficult for them to upgrade them all. Otherwise, I can't really see much reason for not upgrading. 2.1 did fix a number of issues, and it did slightly improve the performance of PCI-GPIB compared to the 2.0 driver.

We w
ill look at adding the timeout information to the documentation for the asynchronous calls.

[ndiamond]

We're using Visual C++ 6. Yesterday our customer's demo systems also had Visual C++ 6, though as mentioned they had Windows 2000 as opposed to our Windows 98. We were told that their customer will likely use Visual C++ .net, though I don't know which year's version.

I was preparing to use either Visual C++ 6 or Visual Basic 6 as the need might arise, but Basic turned out to be unnecessary.

[ndiamond]

Last night my boss and I agreed that I will install the US version of the 2.1 driver on one machine and see how it goes. Both machines in my testing have Windows 98 Japanese and presently have the 2.0 driver in Japanese. An English-language driver should be OK at the driver level, and I already downloaded it earlier, so I'll try that for 2.1. (Further comments below.)

I don't think our customer would really be reluctant to upgrade to the 2.1 driver, but we have to be very careful in making recommendations to customers. Business relationships take priority over engineering. I think we will be able to tell them now that National Instruments gave particularly strong recommendations to upgrade to 2.1. An intuitive guess is that our customer's customer has a large number of systems but I hope that the importance of the upgrade can be communicated to them.

I hope to be able to participate in or observe a test with the 2.1 driver and Windows 2000. If it blue screens then I will post a new message here.

Thank you very much.

(Regarding US or European drivers on a Japanese system, as for whether related components above the driver level would work OK or not, the situation seems to be random depending on who developed a program at any particular time. For example an English-language program might specify an 8-bit font for dialog boxes, but call an MFC method to display a dialog box containing some default strings. The default strings are unreadable because they are Japanese but get shoved through an 8-bit font. If a program contains all of the text labels that ever get displayed and really keeps everything in English then an 8-bit font is OK for that. But there can be obvious problems in displaying filenames etc. A correct solution is to let the OS choose a font based on the program's wishes plus the OS's knowledge of the OS's human language version or settings. Of course these details are off-topic for this discussion, but since these problems do happen with some products, this is the reason why I did not experiment with a US-version driver yet in this task.)

[ndiamond]

Oh, the 2.1 driver download already includes the Japanese version. すごい。 Installing it now.