Visa Close.vi takes 15 seconds to complete (too long)

[AM7723]

It's as the subject of the post says. Visa Close.vi takes 15 seconds to complete, during which my program is stuck and I'm unable to do anything.

It would've been ok if it was only 1-3 seconds, but 15 seconds is too much. How can I shorten it?

I already tried flushing all buffers and using the CLEAR Visa function too to no avail.

I'm adding the "Config serial port" function and the Visa Close with probe list that shows it took 15 seconds to complete:

I'm using Labview 2017

[GerdW]

Hi AM,

---

@AM7723 wrote:

It would've been ok if it was only 1-3 seconds, but 15 seconds is too much. How can I shorten it?

---

Which device are you talking with?

Which kind of port do you use?

Which kind of port hardware do you use?

[altenbach]

I agree that you post so far has virtually no useful information, and adding a stamp sized blurry picture of a tiny portion of a diagram seems quite useless. What are we supposed to look out for? Why are there all these local variables? What are the values of all these controls and wires? What does the code actually do? Where's the rest of the code?

... and as has been asked, what are the hardware details? Does the instrument communicate correctly before the close? Is your timing during a regular run or during execution highlighting? How often does the config serial port execute during the run?

[Kevin_Price]

The specific amount of time 15 seconds actually rings a bell.   We ran into something similar a while back, but am not sure I remember details correctly.  Here's what I *think* I recall:

One of our modules opened up a serial connection, then spun up an asynchronous tight loop that kept calling VISA Read.  Timeout errors were common, expected, and handled (ignored).  This method was used to minimize latency when receiving info from our serial device.

As I recall, there was a scenario where we ended up losing a race condition during shut down.  A message was sent to the VISA Read loop to tell it to stop, and soon after that we called VISA Close from the main module (which as also where we originally configured the serial connection). 

The problem was that the VISA Read loop might not notice and act on the stop message until after its most recent Read attempt finished.  Meanwhile, the main module progressed to the point where it also called VISA Close.  This was meant as a failsafe, but something about attempting to Close while a parallel process was in the midst of a Read caused the Close to take just about exactly 15 seconds to execute.

Fortunately the fix was pretty easy, we just had to stop trying to Close when we could be in the midst of an attempted Read.

Is it plausible you could be dealing with something similar?  Is your code structured in a way that you could be calling Close while another part of your code is attempting to Read?

-Kevin P

[Edit: P.S.  Note that this behavior seems to be somewhat unique to VISA Close.  A similar technique works without delay for other "close" operations such as clearing a DAQmx task while other code is reading, releasing a queue while other code is dequeuing, etc.  Probably the failsafe had been tried for one of these other cases in the past and then the pattern was just carried over for this VISA Close.]

[rolfk]

That's very likely what is happening. VISA is a little special in that it looks like a LabVIEW native API (you can't go into the yellow icons) but it is a fairly thin layer around the visa32.dll, but built in into LabVIEW. While closing most LabVIEW resources will actually abort any executing operation on that resource, VISA is a little bit different since much of the asynchronous handling is done by default in VISA itself. It may be interesting to try to change the Synchronous I/O Mode of the VISA Read node to Synchronous for a test to see if that might make a difference.

But synchronous operation it is not an ideal solution if you want to communicate with more than 4 devices.

I think I have an idea how this might be fixed in LabVIEW but can't do that myself.

[AM7723]

Thank you!
Changing the Read function to Synchronous fixed the problem.

As for Kevin_Price you're right, I do have an RX loop in which the read function is called. So I put the read function inside a case structure and before I close the visa I disable the condition and thus stops any activity. Thank to you both!

[Martin_Henz]

Be careful with syncronious mode in such situations. LabVIEW can crash if you use larger timeouts. LabVIEW dev. system closes without any additional error message.

Actually tested on two PCs with LabVIEW 2021 SP1 (21.0.1f2)

Attached file saved for LabVIEW 18