Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

VISA RS232 read freeze -> LV stuck on "resetting vi" -> VISA resource inaccessib

Solved!
Go to solution

I have a simple vi (attached) that reads from a serial port (actually, a USB to serial converter) in a timed loop (in case you wonder why the vi is written the way it is, the instrument I'm trying to read sends status messages every 20 ms, but I only care to read one every 2 econds or so, so I can safely discard the others).

 

The vi starts fine, but after a randmom number of reads (can be tens, hundreds or thousands) it freezes, and neither the "stop" button programmed into the vi or the "abort" button can terminate it. However, LabView is still responsive at this point, and I can close the VI, which results in a message "resetting VI: [vi name]" being displayied by LV indefinitely. The only alternative is to force close LV using TaskManager. Unfortunately, when I subsequently try to acess the VISA resource using either LV or NI MAX, I get an error message: 

 

Error opening resource:
ASRL3::INSTR

VISA: (Hex 0xBFFF0072) The resource is valid, but VISA cannot currently access it.

 

The only way of accessing the resource again is to completely reboot the system (even disconnecting and reconnecting the USB adapter seems to have no effect).

 

I found a number of similar posts in the forums, but none contained a solution. I tried to implement a few suggestions found there (like disabling power management on the USB controller and inserting a delay between subsequent read operations) without success (although since I inserted the delay the problem seems to appear after a longer time).

 

I also captured a trace of the VISA communication, that I'm attaching. You can see at line 138 that the read operation did not return. This is the point where the vi freezes. The subsequent messages are a result of me closing the vi, force closing LV and then trying to access the resource again.

 

Any idea?

 

Thanks

 

Giacomo

Message 1 of 18
(4,480 Views)

Would you mind providing the answers to a few questions?

1. What version of LabVIEW and operating system are you using?

2. What instrument are acquiring data from?

3. Have you considered using a standard while loop with timing inside instead of using a timed loop?

4. Are you able to stop the VI before it stops reading? 

Thanks!

Rick C.
0 Kudos
Message 2 of 18
(4,446 Views)

Sure. I should have put it in my original post...


1. What version of LabVIEW and operating system are you using?

Windows 7 Enterprise 64-bit, Labview 2012, NI-VISA 5.4

2. What instrument are acquiring data from?

It's a pressure gauge (Oerlikon Ionivac ITR 90). It sends a string of 9 bits every 20 ms, continuosly.

3. Have you considered using a standard while loop with timing inside instead of using a timed loop?

It makes no difference for me (It seemed like a timed loop was easier, but I ca change easily). Do you see a reason why this would be related to the readout problem?

4. Are you able to stop the VI before it stops reading?

Yes. Normally I can both stop it with the stop button of the timed loop, or by aborting it (although that doesn't close the visa resource...). Once it "hangs" on the reading operation, however, well... I've described what happens in the original post.

 

I should also mention that I tried it with two differnt brands of USB->RS232 adapters, and I got the same behaviour.

 

Giacomo



Thanks!


 

0 Kudos
Message 3 of 18
(4,441 Views)

A timed loop is generally used when you want to be very deterministic about your timing, which might be the case for real-time applications. You may want to switch to a while loop to be sure timing isn't prioritized over the functionality of the code. If that doesn't help, we can go from there!

Rick C.
0 Kudos
Message 4 of 18
(4,436 Views)

I did replace the timed loop with a normal while loop containing a "wait" vi, but the problem is still there. It hung after about 5 minutes...

0 Kudos
Message 5 of 18
(4,407 Views)
Highlighted
Solution
Accepted by topic author giacomociani
08-27-2015 04:09 PM

Hi Giacomociani,

A problem you may be facing is the uncertainy in bytes contained in the read buffer when you decide to read. If the buffer is empty, it may wait continuously at the the read function, thus resulting in your program "hanging". Something you may want to try is a case structure that only reads if a certain number of bytes are in the buffer. Give that a try and see if you still encounter the issue.

Rick C.
Message 6 of 18
(4,392 Views)

Wow, you got it!

 

I'm a little surprised, as I though I had excluded this possibility in me previous tests... but I had done that by reasoning on when the hang-up was happening, and concluding that it couldn't bedue to the buffer being empty. Apparently, I didn't consider all the possible cases. Also, I did not expect the read operation to "freeze" if the buffer is empty, but just to return an empty string...

 

Anyhow, now I have modified the code so that the condition never happens, and it has been running for an entire day without hanging (absolute record). I'm going to leave it running over the weekend, but I'm pretty optimistic!

 

Thanks for the help!

 

Giacomo

 

Message 7 of 18
(4,366 Views)
I can't look at the VI but my guess is that you have the termination character enabled. In this case, the read will wait until the termination character is detected or the timeout value is reached. It's not freezing, it's just doing what you programmed it do. The case statement is an appropriate addition though you might want to investigate why 0 bytes are occasionally available.
0 Kudos
Message 8 of 18
(4,359 Views)

Hi Dennis,

 

thank for the answer. No, the VI is not programmed to look for a termination character (I run into other troubles earlier because I didn't know that was the default behavior, but since then I had it set to false).

 

Regarding the VI "not freezing, but doing what I programmed it to do", I have to disagree. I'm happy to have found the problem, but I still think that the LV behavior in this case is to be considered a bug (either of labview, of the serial driver or the design of the serial bus itself, I don't know), for at least a couple of reason:

- normally, if I ask the VI to read 20 bytes and there are only 10, it returns with the 10 it found. So, if there are "only 0", why doesn't it return with 0 instead of waiting forever? In the other case it doesn't wait forever for the additional 10...

- even so, when I _abort_ the program, I would expect it to abort whatever is doing, not hang the entire LV environment on a "resetting VI" command and then spoiling (in which way I don't exactly know) the VISA resource so that it's not accessible anymore unless I restart the computer...

 

As for the reason why I get 0 bytes occasionally, that is partially the result of a maybe lazy implementation of my routine. The instrument sends a message of 9 bytes every 20 ms, without request. I only want to look at it every couple of seconds, and get the latest message sent, without particular care of the exact timestamp (at the few milliseconds level). So what I do is this:

- I have a loop running every 2 seconds

- at the beginning of the loop. I flush the buffer (otherwise I get the older messages stored in the buffer)

- then I read two bytes, and I check if they correspond to the sequence that identifies the beginning of the message (an that cannot occur in any other position in the message)

- if they do not match, I read the following two

- if they do match, I read the following 7 and interpret my message, then I start the loop again

 

Now, I suppose that if I flush the buffer in the middle of an incoming message, and an odd number of bytes get lost, I will start reading bytes in pair until the end of the message without finding a match. If the entire operation completes before the next message arrives (very possible), I will eventually try to read an empty buffer. For now, my quick and dirty solution has been to insert a 30 ms delay between flushing the buffer and start reading the again (so I'm sure at least one message arrived), but I do agree it's not a great solution: a case statement would be much more robust... next time I stop the routine I'll made the change! :-)

 

Giacomo

0 Kudos
Message 9 of 18
(4,351 Views)
No. If you request 20 bytes and the VISA Read returns 10 without a timeout error, it is detecting a termination character.
Message 10 of 18
(4,347 Views)