VISA Read hangs. Get Resetting VI dialog on abort.

[nyc_(is_out_of_here)]

---

@elifino wrote:

You're making it much more complicated than it is.

If you send a query with a 5 second timeout and there's a glitch on the communications line so the response never comes, then the defined correct behavior is for the driver to return control to you after 5 seconds with an error message. But the driver doesn't do that. So there's a bug in the driver. It doesn't work according to its own defined correct behavior.

Standards or not, any real hardware has a nonzero probability of a glitch. You may be able to go 30 years and never see it, or you may be able to reproduce it on demand, depending on what hardware you're forced to work with. But when it happens, the low-level software shouldn't hang. It should error out. Just like the documentation for it says it will.

Nobody's saying the hardware should be able to communicate in absolutely any environment. Nobody's saying the software should be able to survive an arbitrary glitch inside the computer itself. Congratulations, you've beaten the straw man to death. Now can we just have a VISA driver where timeout means timeout?

---

And as I wrote before, when you put in poor programming practice and use of USB-GPIB, USB-RS232, I am not sure what to believe.

[George_G]

elifino pretty well summed up my thoughts about this situation.  I don't expect the GPIB to be able to communicate the data across the bus under any circumstances.  When I said a driver should be robust, I really meant it should do its best not to wrench control away from me. In adverse conditions it should fail in as nice a way as possible.  To me, a bus upset from EMI is not that different from a broken cable or an unplugged instrument.  In all three situations I intuitively expect the communication to fail and the driver to return an error.  But in the bus upset case what I get is a VI that hangs, requiring a restart of the whole environment.  In general I don't like when things fail by hanging up and becoming unresponsive.  I want error codes and to have the control returned to me.  I call those hangs "bugs", but it's just a word, and it means "behavior I don't like."

In terms of this thread, I think it is valuable information for future users to realize the timeout feature of the VISA session is not infallible: in some cases VISA will choose to wait forever on an unresponsive bus.  If someone is experiencing this (very frustrating) symptom, it's useful to know it is hopeless trying to solve it programmatically; the problem lies with the hardware one way or another, and I've given a few clues where to focus some effort.  I hope it save someone some time.

[Heckler511]

I agree it's impressive how long this thread has stayed alive. 

Everyone is right in my opinion.  If your lab is littered with broken appliances and frayed wires and you got extra EMI floating around it's sorta your fault. 

Crappy hardware also helps confuse things.  In my case I purchased new hardware that cost around twice as much, and the second set was more robust in terms of being less subject to random EMI events.  DO NOT BUY from EasyDAQ.biz - there is a reason their hardware is so cheap.

But this is also something that should be higher up on NI's radar.  I had a subscription to NI's call-in help / support line when I was dealing with this, and nobody over there knew of this type of problem.  Even the VISA specialists.  Only after many hours and finding threads like these and pointing it out to the folks at NI were we able to agree about the problem I was seeing.  And George is right, I can code for unplugging and replugging my hardware and the program keeps running.  The drivers should be able to recover from EMI bus interruption / timing issues.  In my case, some of my computers would get so mangled from this occuring reaptedly that I'd get blue screens and computers that wouldn't boot up, etc. 

Anyway, it's a good thread.  Hopfully it will save the next new programmer dealing with this the two weeks plus it took me to figure out what the heck was going on.

[tcap]

Hello All,

I am sorry for the inconvinence you are experiencing, and thank you very much for bringing this to our attention.

I will forward this information to the appropriate departments.

Regards

[Alisha_P]

R&D is investigating this issue, but there are a couple questions.

First of all, it seems like the majority of posts concern using VISA with GPIB, so that's what we're currently focused on.

Another thing to note (which I think has been mentioned at least once) is that when the VISA Read is set to "synchronous", VISA calls into the ibrd function provided by the GPIB driver, which then handles the timeout. I only point this out because it might not be appropriate to focus on VISA. Can anyone comment on whether they're seeing this issue with synchronous or asynchronous calls?

Also, it would be very helpful if someone could provide an I/O Trace before and during the hang. I realize this might be pretty difficult since it is often intermittent but I know some have said they are able to reproduce it reliably. We would want an I/O trace with LabVIEW disabled in Tools>Options>View Selection. Then we would want one with LabVIEW and VISA disabled. This would allow us to see whether the hang is occurring in LabVIEW or VISA or GPIB.

[mdg]

Found this thread while dealing with the same issue over the past few days.  I've got my application working now, but I can answer a few of your questions.

---

Alisha_P wrote:

First of all, it seems like the majority of posts concern using VISA with GPIB, so that's what we're currently focused on.

---

I encountered the error while using VISA for serial communications, so it seems to be more general than just GPIB.  Symptoms were the same as others have reported.  In my case, it was a simple VI that used a loop to poll an instrument repeatedly.  The VI would execute as intended for a while (the exact length of time varied) before locking up.  The stop button did nothing, while closing the window brought up the "Resetting VI" dialog requiring a force quit of LabVIEW.  In general also had to restart the computer to reclaim the COM port since LabVIEW shut down untidily.

---

Another thing to note (which I think has been mentioned at least once) is that when the VISA Read is set to "synchronous", VISA calls into the ibrd function provided by the GPIB driver, which then handles the timeout. I only point this out because it might not be appropriate to focus on VISA. Can anyone comment on whether they're seeing this issue with synchronous or asynchronous calls?  

---

I can say that for me the issue definitely had to do with asynchronous calls.  When I switched the I/O mode to synchronous, the errors went away (!).

I'm not equipped to do an I/O trace, but I was using an independent program to monitor the serial port during testing.  It appears that when the I/O mode is set to asynchronous the hardware is given a timeout of 1 ms regardless of the VISA setting. It then continuously times out while a read is in progress, transferring whatever data has come in in the last millisecond.  At 9600 baud, this was either no data at all or a single byte, so that a full ~200 byte read might involve 200 - 300 distinct timeout events. When the error occurs, this chain of reads stops abruptly.  Whether that's due to a hardware failure or to VISA no longer asking for them I don't know. I will note that when everything is working correctly the VISA timeout setting still worked, it's just not being set in hardware.  I interpret this to mean that the timeout is being managed somewhere further up the chain.  In contrast, when the I/O mode is set to synchronous I can see the timeout I've specified getting passed down to the hardware, and when I perform a read it comes back as a single block of data of the length requested.

I'm at the limits of my understanding of how these drivers work, so I'll leave it at that and let the more knowledgeable folks interpret as they see fit.  I will say that the I/O I was doing in the polling loop worked fine until I put it in a loop (regardless of I/O mode setting).  This suggests that the error had something to do with the volume and/or frequency of calls.  Whether that just increased my susceptibility to EMI as previous posters have suggested, or swamped the hardware to the point that it failed, or something else, I'm not sure.

Hopefully this will help you guys sort out the issue.  In the meantime, it seems that setting the I/O mode to synchronous (if your application allows it) may be all that's necessary to fix the problem.

[rpdavis]

Alisha_P here is a little more info for you and your team.

I have a similar problem where the VISA Clear VI hangs with a Digi ME Ethernet to RS232.  In testing I found if I lose communications to the module the VISA Clear VI hangs stops until communication is restored. 

So it looks like this problem with failure to time out is problematic to several VISA functions.  (LabVIEW 2013 SP1)

[Jeannius]

Here's an IO trace as asked. 

I did stop the trace before getting the actual "resetting VI" pop up.

[Craigginsberg]

Hello all in this thread

Me Too!!!

I must continue to resurrect this thread.

I am experiencing the same problem.

Visa Read Hangs 😞

I am unable to figure out how to do the I O trace. My app is frozen right now at this very moment. If some one gets back very soon with instructions to collect any diagnostic data I will try and comply

My application performs serial reads continually in a wet dirty loud dusty indoor/outdoor industrial environment with lots of machinery. One test we do is a thermal cycling test requiring logged temperature and humidity data from many sensors. My labview app is optimized to allow me to pan and zoom through months and years of data. So I leave the app recording data for weeks at a time. Sooner or later i get this visa read hanging problem. I am developing an all ip67 aluminum housing and purchasing shielded sensor wires. I will report any observations. The problem is so intermittent.

[rpdavis]

Hello Craigginsberg

I’m probably to late this time but this is how I get to NI I/O Trace, but if it is already locked up like mine does it’s too late to get a trace.

MAX → Devices and Interfaces →, double click your com port, select NI I/O Trace

Good luck I don’t think NI thinks this is a big enough problem to allocate the required resources to fix it quickly. One day I’m sureeeeeeee they will get it fixed.