error -1073807339 on VISA read

[drjenk]

Hello,
I am getting intermittent read timeout errors (-1073807339) on visa read (query of current level) from and Elgar EW801 AC power source.
I have looked at the knowledgebase, and came across a post having to do with this issue under LV 4.1 and win95. The solution was to add "syncVisa=true" to labview.ini. I am running winNT4 and LV5.1.1, but I tried the solution anyway with no positive results, in fact it seemed to make the problem worse, so I removed the line.
I have also noticed the problem seems to happen more often when I do a lot of task switching in windows while the test is looping. I can get it to happen within 4-5 loops as opposed to <50 normally.
I have tried adding delays before/after the read with no positive resul
ts, still intermittent and reproducable.
Is there any global VISA read timout setting anywhere to possibly increase this value?
How do I tell which version of VISA I am running?
What are your suggestions for this situation?
It is causing a large hit on yield reports with our product.
Thanks
David Jenkinson
253-335-6056

[JoshuaP]

Hey David,

You will need to place a property node on your diagram. First set the class to "VISA->I/O Session->Instr" by right clicking on the property node.

Then select the "General Settings->Timeout Value" as the property. This will allow you to wire in a control or constant to the timeout and this should fix your problem.

I hope this helps out.

JoshuaP
National Instruments

[Dan_Mondrik]

David:

Older versions of LabVIEW and NI-VISA had a few issues with async I/O that have been discussed widely in the various forums. If upgrading LabVIEW isn't in the cards for you at this time, there might be a couple of other (free) alternatives to try.

One of them is to obviously increase the read timeout like Josh suggested. Another is to upgrade your NI-VISA, which should be backward compatible to LabVIEW 5.x. A final suggestion is to create a read wrapper VI that calls VISA Read, then if it times out, sees if any more data is available at the port and calls VISA Read again. That last suggestion is a hack, but sometimes hacks are in order.

You asked what version of NI-VISA you have. There are a few ways:
1) Manual/best: look at the readme.t
xt in Start>>Programs>>National Instruments>>VISA, which should say the version right near the top
2) Manual/alternative: right-click on \system32\visa32.dll and look at the version resource
3) Programmatic: drop a VISA property node and choose Version Information>>Version of Implementation. Treat it as a hex value formatted like MMMmmmss (Major, minor, subminor). In other words, 0x00200601 would be 2.6.1.

Dan Mondrik
National Instruments

[pjwesson]

I tried the two solutions posted above using LV 6.0, but am having no luck with either. I've set the read timeout as high as 10000ms and still have the error propagating.

Any suggestions would be greatly appreciated.

Thanks

[drjenk]

Hello Dan,
I have put the read retry loop in, it seems to be catching the error and masking it fine, transparent to the user and yield results, but the underlying problem is still there. I have it logging everytime a read error happens (I did also lengthen the visa timeout by the method mentioned above). So even though the workaround is in, I'm contemplating upgrading my VISA installation to get rid of it altogether. I looked and my version is 2.0. Was this problem known to be there in this version? In other words, does it make sense to upgrade to fix this problem, or should it have been gone by this version? Trying to avoid any unnecessary potential problems resulting from an upgrade.
Thanks
Dave Jenkinson

[Dan_Mondrik]

Dave:

There have been enough bugs fixed that it's definitely worth trying to upgrade to at least NI-VISA 3.0. If you're using Windows 95, NI-VISA 2.6.1 was the last to support that OS; 3.0.1 was the last to support Windows 98/Me. NI-VISA 3.1 is current on NT/2000/XP.

We definitely fixed one bug related to data not being reported when the data arrived roughly at the same time as the read thought it timed out. I know there has also been a fix in LabVIEW to go back and check once more when it thinks it has timed out. But the fix on our end won't hurt.

Dan Mondrik

[drjenk]

Ok, I will probably try the upgrade to 3.1.
It should be seamless, right? In other words, it is another layer underneath labview, and I shouldn't have any broken vi's or anything afterward? This is a production tester, the only one running labview, and I'd hate to bring it down for something that wasn't completely necessary.
Thanks
Dave

[Dan_Mondrik]

Dave:

Yes, it *should* be seamless. We didn't explicitly test NI-VISA 3.1 against LabVIEW 5.x, but I still have it on my development machine and it seems to work just fine.

We don't make any changes at all to the VISA-related files in the LabVIEW 5.x directories (NI-VISA 3.1 does some upgrades to the VISA-related files for LabVIEW 6.0 and higher) so I can say with a high certainty that you won't have any broken wires.

Dan

[ScottieB]

Hello,

Are you having intermittent timeout issues as described above? What version of NI-VISA do you have? Are you doing serial or GPIB communication? What version of 488.2 do you have if you are doing GPIB? Are you able to get anything back from the instrument ever?

To start, do run the example programs that ship with LabVIEW for the appropriate type of communication that you are trying to accomplish. Make sure that you are sending the proper commands to your instrument; if your commands are not correct then your instrument may not respond.

Post here if you need more assistance.

Scott B.
Applications Engineer
National Instruments

[pjwesson]

Scott--

Thanks for the response. I found my problem was due to setting the byte count to a constant rather than using the bytes written from the VISA write.

--Paul