VISA Read hangs. Get Resetting VI dialog on abort.

[merrico]

I am also getting read timeout problems using "GPIB Read."  The program just stops responding and I have to control-alt-delete, start task manager, and end task to get it to stop.  The problem started happening when I switched from Labview 2010 to Labview 2012. 

Going back through the NI Trace I can see that the communication commands have changed from synchronous to asynchronous.  The last command sent before becoming unresponsive is ibwait(UD5, 0x0000).  From what I understand, this ibwait command with a mask of zero is not supposed to wait at all.  It's supposed to return immediately with status information and I think it is also used to resync the program with the driver.  Well it doesn't seem to return in my case.  It just sits there.

That's when I noticed I could right-click on the VISA and GPIB icons and set the "Synchronous I/O Mode" property to synchronous.  This solved my problem.  It now uses the ibrd command to read from the instrument and successfully times out instead of becoming unresponsive.

I am not sure how this relates to serial communication but I noticed the option for synchronous or asynchronous communication is still there.  It might be worth a try.

[jcuuser]

I know this is old, but I have had similar problems and have found a possible solution.

I am interfacing with an old Conductus LTC-10 temperature controller, and was able to solve the problem by splitting each string into a character array, and sending one at a time.

I suspected the issue may have been sending too fast for the old equipment.

I also gave a 1ms delay between writing and reading

[yourzgautam]

Actually I want to know something from the author of this question.How did you programmed srs900 mainframe using labview? I am trying for a long time to do that...Please attach a sample programme if you have one...PL...

Gautam Mitra

[Heckler511]

I'm having very similar issues.  Tens of thousand of successful write commands before Labview hangs on a viWrite.

Have people considered EMI knocking out the hardware / confusing the driver?  Take a look around if you have other instruments / appliances attached to the same power circuits.

[elifino]

It seems like this forum is loaded with questions and no answers. Seriously, Timeout should mean Timeout! It shouldn't be possible for the driver to hang if the timeout is finite. This has to be a bug in NI-VISA.

Does ANYONE have a solution for this?

[Heckler511]

I purchased new hardware - twice as expensive.  Exact same drivers.  My application works fine now

[Shahrukh]

I had the same issue.  Switched from prolific (pluggable uses prolific chips) to FTDI and problem solved.

[JÞB]

For those future thread readers.

Problem: Keithly instruments may hang and not return 

Reason: you  are most likely opening and closing the VISA session inside a loop (DON"T DO THAT!) and you are using a cheapo means to talk to it like a poor excuse for a serial link (Prolific chip set) and have a crappy USB HUB.  

Solutions:

• Buy an externally powered USB hub with good power specs and protect it from the OS (device manager power options) and users (when Joe Schmuck sticks his virus ladden USB 1.0 thumb drive into your high quality USB 3.0 HUB guess what happens to your system?)

• Open VISA Sessions ONCE - use a "Resource Module" (Ben's famous Action Engine Nugget is always a good read. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801)

[George_G · Accepted solution]

I originally started this thread, and it has been amazing how long it's lived, with nearly all of the responses being "me too!".

We don't open sessions in a loop or use questionable hardware.  Our GPIB cards are NI's own PXI version.  The problem has been notoriously difficult for us to track down because it is so intermittent, and when it does happen we are invariably focused on something else.

Recently however we were conducting an experiment that produced a lot of EMI.  And while running this experiment, we got the exact behavior described in the first post of this thread.  In fact, it happened so much we were finally able to recreate the situation over and over.  The instrument could run for a long time, we turn the EMI on, and bingo, VISA hangs on a read operation.  (In this case, it was something other than a Keithly).

We finally concluded for ourselves that there is a bug in the VISA driver whereby it will enter an infinite wait for a bus event that it missed because of electrical interference.  I suspect this root problem (an improperly implemented timeout) causes all the "me too" problems.  Whether because of experiment generated EMI or cheap hardware with poor electromagnetic susceptibility, once VISA misses the bus event, it will never come back.  Since it is way down in a DLL, the LabVIEW and the VI will never come back either.  From the application code we have found nothing a programmer can do to anticipate this problem or correct it once it happens.

Our work around while we wait (holding our breath, of course) for NI to address the bug is to improve EMC (different hardware, or rearrange the hardware), reduce EMI (modify the experiment and improve the shielding), and conduct bus operations during quiet times of our experiment when possible.

[elifino]

Many thanks, George_g! That's about the first real information I've seen on this thread.

I stand by my original assertion. Timeout should mean Timeout, and if it doesn't, it's a bug in NI VISA. Some hardware connections will inevitably be flaky, and a proper communications driver should be able to deal with that. Not all of us have the luxury of being able to specify every detail of the environment or the hardware we're using. As it stands, there is NOTHING a user can do (short of writing their own VISA low-level code) to make the communications robust.

It also appears that this very elementary bug has existed for a very long time and has caused problems for a lot of people. I also strongly suspect it wouldn't be hard to fix: Look at the code that implements the Timeout feature and figure out when it can fail. Probably a single try-catch construct would fix it. But only NI has access to the code, and it looks like they simply aren't going to do it.

Can someone just write an open-source VISA driver so we can be done with this kind of nonsense?