07-28-2023 03:13 PM
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.
This gives the following error after an excruciatingly long 2 minute timeout.
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.
07-28-2023 04:23 PM
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.
07-28-2023 05:09 PM
@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 ;))
07-28-2023 07:43 PM - edited 07-28-2023 07:43 PM
@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.
08-01-2023 08:00 AM
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