viRead timeout error VISA

[BruceH]

I have a program written in VB 6 several years ago which will talk to a GPIB device using VISA. It has always worked fine. Now we have a situation where we have an NI PCI-GPIB board on an Windows XP machine where viRead often results in a timeout error. If I send the same query multiple times eventually I get a response from the device using the exact same viRead code. To make this even stranger if NI Spy is running the problem goes away and there a no timeout errors at all. This tells me there is not likely any problem with the GPIB device I am sending the query to but there is a some issue with my NI software. What could NI Spy be doing to make it work? Why doesn't it work with this setup but has worked previously? Nothing has been changed in the source code. The only difference is this is on another operating system with newer versions of NI software.

I found another article with someone having a similar strange issue where NI Spy resolved it :

http://forums.ni.com/ni/board/message?board.id=180&message.id=12773&requireLogin=False

We have the following hardware and software installed on the machine in question:
PCI-GPIB board
NI-488.2 ver 2.10
NI SPY ver 2.1.0.12
VISA32.DLL ver 3.2.0.19
Measurement & Automation Explorer Ver 3.1.0.3021

Any help appreciated.

[JLS]

Hello,

IS the device you are talking to relatively old? One possibility is that the device communicates slowly, where perhaps the time between writes and reads on your computer side is very short, but the timing required by your device may be longer. I would try putting a delay between writes and reads. NI-Spy may be fixing this because it will in general slow down programs which make calls to NI-VISA because the calls and associated data are being recorded.

One solution, noted in the previous stream, may be to run NI-Spy in the background, however programmatcially implementing delays may be a more stable solution, especially if you choose to take your program to other computers.

Give this a try and definitely repost with the results!

Thank you,

Best Regards,

JLS

[BruceH]

Thank you for your post. The device is old. I have added delays to my code to determine if thats the problem. I will post the results on Monday. The device is in another location and I can not have it tested until then.


Bruce

[JLS]

Sounds great; I look forward to the post!

Best Regards,

JLS

[BruceH]

JLS,
We tried the code with the 75ms delay in it and it worked. So it appears you are right the GPIB device is not working right with the newer faster computer. My company makes the GPIB device so we will have to look into it. We are using a TMS9914 GPIB chip I believe. I'm not a GPIB expert but shouldnt there be some protection in the GPIB chip which would prevent a buffer overflow if thats whats happening? It seems like the GPIB chip should not allow the GPIB master to send a command if it is not ready for one.

Thanks for your help on this.

Bruce

[JLS]

Hello Bruce,

I think what happened with older instruments in general is that when GPIB communication was relatively comparable to the processing speeds of computers, the instruments would deassert NRFD (to say that it is ready for data) before the firmware is actually ready for data, in an effort to speed up overall throughput (predicting that it would actually be ready before the CPU side GPIB interface could send it). Well, the CPU side GPIB interface sees the instrument as ready when NRFD is deasserted, and sends data immediately... in this case doing so fast enough that the instrument receives it before actually being ready to process it. Thus, I don't think it is a matter of protection built into the chip itself (hardware), rather the programming of the chip that would cause this behavior to happen.

In any event, I'm glad we were able to diagnose the issue!

Best Regards,

JLS