LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Intermittent VISA Errors *Help*

Hello,

 

First post so please be gentle. I inherited this code from a former employee of mine. We use this VI in our main routines when we need to talk with some of our devices under test. It has served us well, but recently i have been getting very inconsistent errors related to the VISA Open. Please see attached from screen shot. I have also attached the code. I cannot really seem to find anything related to the errors i am seeing in the forums. At least nothing that stands out. 

 

Anyone willing to take a crack at the code and poke holes in it for me? Anything look out of place? 

 

Thanks,

 

Ryan

Download All
0 Kudos
Message 1 of 6
(2,832 Views)

I'll try to poke a little bit.

 

First question, anything you can think of that changed between when it ran with no problems to when it started acting up?  Changes in com ports (add a port, change an apapter)?  Any special updates like when IT gets in there and decides it is time to update programs?

 

One problem I see is that you are continually opening and closing the port in every while loop iteration.  You should only need to open the port and configure it before the while loop and close it after the while loop.  (Actually, you while loop is more like a 4 iteration For Loop.)  I imagine this is actually a subVI to a larger program and this subVI is repeatedly called.  ??   If so, opening and closing the serial port should be done in the main program, not every time this subVI is called.

 

There is no need for the VISA open, the VISA Configure basically does that already.  VISA Flush of the Receive and Write buffers is also unnecessary because they would already be empty upon opening the port.

 

You really shouldn't need the Bytes at Port.  Including that is wrong about 99% of the time.  Since you have enabled the termination character, just read # of bytes larger than the longest response you expect to get.  The VISA read will return the full response as soon as it gets the termination character.  You can then get rid of the Wait and Bytes at Port.  This would allow your subVI to return more quickly.

 

Those would be improvements to the code, but wouldn't directly affect the error you are getting.  It is probably better to pass the error up to the higher level VI and handle it there.  Having 2 error dialog pop ups in this subVI could be rather annoying to the end user because they would happen repeatedly.

 

An invalid VISA resource means you are either losing the VISA com reference coming in.  (Any loops or case structures in your main VI that is giving you default data on the purple wire?)  Is the Com port disappearing from MAX or Device Manager when these errors occur?  Is this com port a USB adapter and your PC is shutting down USB ports as a "power saving measure"?

Message 2 of 6
(2,817 Views)

RavensFan, Thanks for taking the time to look it over. 

 

I do not believe that there has been any major IT updates or port changes recently. I have noticed this error happening more since i updated all of the programs to LabView 2016. Maybe the error handling just works better? 

 

You are correct, this is a subVI to a larger program. Yes, we call this subVI about 6 times throughout the whole routine. So you are suggesting we really only open and close the serial port in the main routine versus running this subVI everytime? This was my initial thought, it seemed excessive. I do not have a lot of experience on the VISA protocols. 

 

I do not believe that I am loosing the comm port or VISA resource throughout the sequence. I am pretty sure that i have disabled any of the power saving measures for the comm ports. Definitely something i can look into. 

 

I will check these things over and return with more information. Thanks again. 

 

Ryan

 

 

0 Kudos
Message 3 of 6
(2,805 Views)

Like I said, I'm mostly poking holes at what I see.  Those things were things that could be done better, but I don't think are the cause of your issue.  And I'd be hesitant to change too much too soon.

 

If others have ideas of things to look at or fix besides what I said, hopefully they'll comment.

Good luck and I hope you find something soon that makes sense.

0 Kudos
Message 4 of 6
(2,790 Views)

RDalton wrote:  So you are suggesting we really only open and close the serial port in the main routine versus running this subVI everytime? This was my initial thought, it seemed excessive. I do not have a lot of experience on the VISA protocols.

It isn't excessive.  It is the correct way to do things.  At the very least, move the opening and closing of the serial port to be outside of the loop in the subVI.

 

Other smells that I don't think RavensFan hit already:

Writing a byte every 50ms sounds excessive.  Your device can't handle a stream of data?  Even then, that code could be simplified into a FOR loop with the help of a String To Byte Array.

 

The outer loop should be a FOR loop with the conditional.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 6
(2,773 Views)

One other thing I missed earlier.  The 60 second timeout on the Serial Configure is really long.  The default value is 10 seconds, and I think that is still rather long.  My opinion, unless you are expecting a long response like a waveform from an oscilloscope device, any short message device should respond within about 2 seconds.  A 60 second wait means if you do have a timeout error, your VI will feel like it locked up cold to your user waiting for the timeout error to come back.

Message 6 of 6
(2,766 Views)