VISA Read hangs. Get Resetting VI dialog on abort.

[Craigginsberg]

Update:

hello all,

got back to working on my app recently. My Vi was recording temp and humidity data and i left it for a while. I recently came back to it and it seems to have been hanging on this visa read for the last three days.

😞

[Craigginsberg]

No i do not have end characters worked in. How may this help me?

[Stop_Luke_and_Listen]

Hi Craigginsberg,

What hardware are you using?  Also what version of LabVIEW are you running?

[Craigginsberg]

i am using arduino. i am using labview 2014 will install 2015 upgrade when i get a chance as it is already purchased. i did the upgrade to the 2015 visa as recomended in this thread and now my problem is occuring with more frequency then it used to. i used to record data for weeks before encountering the problem. now it will only record for a day or so before encountering the problem

[Stop_Luke_and_Listen]

I saw that previously you got an error when you opened VISA test panel.  Is this still the case?

[Amanda.Ison]

Thanks so much for keeping this thread updated! I can confirm that this issue still occurs with NI-VISA 15.5 and NI-488.2 15.5.

I am using a pulse generator to create a series of high voltage pulses, and it turns out that the (NI, shielded) GPIB cable and (SHV shielded coax) output cables were too close. I can create or remove the problem on command by moving the cables together or apart.

In my case the problem actually manifested in two forms:

1. Additional signals are sent to the instrument (leading it to flood my read buffer with parsing error codes).

2. Visa hangs, as other posters have noted. If I attempt to open the NI-VISA interactive control screen during this time, it fails to find any instruments or ports. After closing LabVIEW it attempts unsuccessfully to reset the VI, and I must end the task in order to regain functionality.

[Madskf]

We have the same issue.

Our program have been running in our 'clean'-lab (No emi) for over a year on five different computer and it has never failed once.The other day I installed a copy in our not-so-clean lab (There is a lot of emi). After 1-10 read-write loops it hangs in the VISA-read and never returns an error. We shielded the cables better and got it to run 100-10000 loops before it hangs in the VISA-read again.

I have attached a NI Trance of when it happens.

After reading about it here I have switched the read and write VISA to 'Synchronous' and it looks like it is working.
I'll report back in a few days to tell if it continues to work.

[Madskf]

The switch to 'Synchronous' did work for us!

It doesn't hang anymore

[ErikMansson2]

Dear NI and co-useres,

I am seeing the basic issue of timeout setting not being respected by the VISA Read, currently when using a driver for a virtual serial port over Ethernet ("COM Port (virtual) to TCP-IP adapter" by INFICON AG, version 22.8.42.308). I have VISA 16.0 and LabView 2013 (13.0.1f2, 64bit) on Windows 7 64-bit.

For this driver I was able to bring it down to a dead-simple test case for always reproducing it:

1. turn off the device (or maybe even leave the COM port unplugged),
2. open a VISA connection with a timeout (in my case 1250 ms). To me it makes no difference whether asynchronous or synchronous.
3. make a call to read a few bytes from it.
4. Since no data is coming I expect to get an error within two seconds, but the VI becomes unresponsive and probes show that the read operation never completes. (Using other hardware, e.g. COM ports directly in the computer, give the expected timeout.)

I agree with some early comments that it is a bug when Read does not time out. Since I have the issue with the Ethernet driver but not with a local port, it may be that NI's VISA can not easily fix the issue on their own (or at least it hasn't happened yet), so we instead need to ask manufacturers of the various driver or firmware for specific serial adaptors (Ethernet, USB, GPIB). Is there any public specification of the interface between VISA and the COM driver that I can point to if I contact INFICON AG to ask for them to improve their driver to respect timeouts?

As a tip for testing (and real situations) I have found that by downloading the free terminal tool hercules_3-2-8.exe and just clicking to Open the COM port there, some kind of interrupt event makes LabView unfreeze and return an error from the Read-operation, so the test-VI can stop normally!

Another suggestion for those suffering from the lack of timeout is to work around it by making your own timeout loop that checks the VISA property "number of bytes at port", and then only call the Read operation if a sufficient number of bytes have already been received to the buffer.

[ErikMansson2]

I attach also the minimal test case, which can be used for checking whether your serial port adaptor (USB, GPIB, or in my case Ethernet) is respecting timeouts. Just select a COM port without connecting any device that can respond (or turn the device off).

When you run the VI on a well-behaving COM-port, it will light up both the booleans within 2 seconds, and the Read-error indicator will show a timeout error code.

When I run it with the INFICON AG virtual COM port over TCP-IP, the second boolean never lights up ("Read-command finished?") and the VI can not be stopped. (As I mentioned in my previous message, I am able to un-freeze LabVIew by opening the COM port from another program, specifically one called Hercules terminal.)

I obtained the TCP-IP driver not directly from INFICON but by using the "Software Ethernet Configuration Tool" downloadable from https://www.pfeiffer-vacuum.com/en/products/measurement/activeline/controllers/?detailPdoId=32066 for a pressure gauge controller.