LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Too short time between Visa close and Visa open

Hi,

 

I am taking over code made by somebody else with the task of solving a seemingly random bug.

I found the source: closing a visa session to a USB instrument and reopening it immediately after (this is due to bad design: every subvi calling the instrument is opening an closing a VISA session)

The application doesn't crash every time, but I can easily replicate it by just looping over a Visa open - Visa close pair as fast as possible and waiting for the error.

 

VISA Open-VISA Close stress test.png

 

This gives the following error after an excruciatingly long 2 minute timeout.

error.jpg

 

Is this due to a bad instrument design?

Is the timeout configurable? It is NOT affected by the normal VISA Open timeout.

 

I could solve it by opening a session once and closing it at the end. Doing it this -normal- way, I can query data as fast possible without any issue.

0 Kudos
Message 1 of 5
(1,173 Views)

Basic architecture flaw.  Open the VISA session ONCE before the loop.  Do all your stuff with VISA inside the loop.  Close the VISA session ONCE after the loop.  You don't need to open and close the session with each iteration.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 5
(1,157 Views)

@billko wrote:

Basic architecture flaw.  Open the VISA session ONCE before the loop.  Do all your stuff with VISA inside the loop.  Close the VISA session ONCE after the loop.  You don't need to open and close the session with each iteration.


The OP mentioned that's how they'd fix it- the problem is that, in their legacy code base, if this error happens it takes 2 minutes to return. The issue is how to get that 2 minutes down to something reasonable so the error could be handled. The VI in that post is specifically to stress test and find the bug.

 

To the OP: according to this thread, which (frustratingly) links to a non-existent KB article, but the post mentioned it was basically giving you an OS-level message. Thus, it's likely a specific configuration thing for your specific device. I'd bet whatever DLL is handling the actual system calls is still in use by the last Close operation before getting called by the new operation. Which USB/serial device are you using? Perhaps you could reach out to them?

 

If it IS a DLL call, unfortunately I don't think you can abort it early. 2 minutes seems like a deliberate wait period (assuming it's exactly 2 minutes). It could also be two 1-minute waits you're hitting.

 

As far as how to fix it, I'm afraid I don't have any ideas other than refactoring the bad code the way you already mentioned. (Of course, right after I post I bet rolf will come in here and tell me all about how the DLL calls can be configured the right way ;))

0 Kudos
Message 3 of 5
(1,148 Views)

@BertMcMahan wrote:

@billko wrote:

Basic architecture flaw.  Open the VISA session ONCE before the loop.  Do all your stuff with VISA inside the loop.  Close the VISA session ONCE after the loop.  You don't need to open and close the session with each iteration.


The OP mentioned that's how they'd fix it- the problem is that, in their legacy code base, if this error happens it takes 2 minutes to return. The issue is how to get that 2 minutes down to something reasonable so the error could be handled. The VI in that post is specifically to stress test and find the bug.

 

To the OP: according to this thread, which (frustratingly) links to a non-existent KB article, but the post mentioned it was basically giving you an OS-level message. Thus, it's likely a specific configuration thing for your specific device. I'd bet whatever DLL is handling the actual system calls is still in use by the last Close operation before getting called by the new operation. Which USB/serial device are you using? Perhaps you could reach out to them?

 

If it IS a DLL call, unfortunately I don't think you can abort it early. 2 minutes seems like a deliberate wait period (assuming it's exactly 2 minutes). It could also be two 1-minute waits you're hitting.

 

As far as how to fix it, I'm afraid I don't have any ideas other than refactoring the bad code the way you already mentioned. (Of course, right after I post I bet rolf will come in here and tell me all about how the DLL calls can be configured the right way ;))


I didn't read that little blip of text between the two pictures.😅  (I was hunting all over to find out where you got the "two minute" thing from.)  To the OP - sorry I thought I read everything, but apparently not.  So just retroactively ignore my post.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 5
(1,132 Views)

For posting a reply on the Forum, I looked up some old code of mine that involved configuring a VISA call to a Serial port coming in on a TCP/IP line.  I noticed that just after I closed the VISA connection, but before I exited from the sub-VI, I put a delay (50 ms?  don't remember), and remembered that this was needed to let the subsequent "Open VISA" call to work.  So try putting a short "wait" after you close the VISA connection.  This might be a "known issue", or it might be "hardware-related" ...

 

Bob Schor

0 Kudos
Message 5 of 5
(1,064 Views)