VISA Open for TCP/IP SOCKET reentrant?

[arteitle]

I'm currently rewriting an application to monitor several instruments over TCP/IP using multiple reentrant preallocated clones running concurrently in subpanels on a tab control, one for each instrument. Formerly it used the TCP Open, Write, Read, and Close functions, but I thought it would be better to use VISA to handle the communications with these TCPIP SOCKET resources, since then I could use termination characters with VISA Read. My understanding was that all of the VISA functions were reentrant. However, I'm finding that some or all of them apparently aren't, preventing my parallel VIs from running concurrently and making my application slow to a crawl. All of the subVIs in the hierarchy between my application and the VISA functions is preallocated clone reentrant, but looking at the NI I/O Trace, it looked like the actual VISA calls were happening serially.

As a simple test I put several VISA Opens in parallel and gave each a different nonexistent IP address. I would expect them to run concurrently and all to time out at about the same time. Instead what I'm seeing is that they're clearly executing serially. Are VISA subVIs supposed to be reentrant, or is this the expected behavior?

Thanks,

Aaron T.

[Ben]

---

@arteitle wrote:

...Instead what I'm seeing is that they're clearly executing serially. Are VISA subVIs supposed to be reentrant, or is this the expected behavior?

Thanks,

Aaron T.

---

"supposed" questions can only be answered by R&D and the spec to which those functions were written.

"Expected"?

I would expect any operation that allocates a resource that involves calls to the kernel to not tolerate interruptions so I would think that would be the way they would have to work.

Q:

Is there a reason why you are choosing to open use then close repeatedly in a loop?

performance in those situation is almost always improved by "Open Once, use repeatedly, close"

For what its worth, my 2 cents,

Ben 

[LV_Pro]

Not sure if this will help, but here is an article on Asynch Multi-Client TCP comms

[Bob_Schor]

We have 24 serial devices connected to two 12-port Serial-to-TCP/IP boxes that give us VISA connections at 2 IP addresses, 12 port each (so our VISA Open looks like TCPIP::172.18.110.1::8000::SOCKET, ...::8001::SOCKET, etc.).  We run each VISA device in its own Start Asynchronous Call "Clone".  The low-level VISA routines are, I believe, "functionally reentrant" as they don't retain State (VISA In and VISA Out), but in any case, we "wrap" them in our own "Open VISA", "VISA Read", etc. functions that we designate as PreAllocated Reentrant Clone.  Works like a champ (the original routine was written using LabVIEW 2011 and 2012 -- I've recently re-developed it using LabVIEW 2016).

Bob Schor

[arteitle]

---

@Ben wrote:

---

---

"supposed" questions can only be answered by R&D and the spec to which those functions were written.

"Expected"?

I would expect any operation that allocates a resource that involves calls to the kernel to not tolerate interruptions so I would think that would be the way they would have to work.

Q:

Is there a reason why you are choosing to open use then close repeatedly in a loop?

performance in those situation is almost always improved by "Open Once, use repeatedly, close"

---

If "supposed" and "expected" are problematic, let me phrase it this way: would you be surprised that multiple parallel VISA Opens to TCPIP SOCKET resources appear to be executing in series, or is that unsurprising behavior? If I replace the VISA Open with TCP Open, they execute concurrently.

I'm not repeatedly opening and closing the connection; I call the VISA Open function with "duplicate session" = false before each polling of my instruments, but per the documentation that should reuse the open session if there is one. I only call VISA Close if the preceding Open, Write, or Read encounters an error. The problem is that instruments which are temporarily inaccessible over the network cause the VISA Open to take several seconds to time out, during which time none of the other parallel threads can continue.

Aaron T.

[arteitle]

---

@Bob_Schor wrote:

We have 24 serial devices connected to two 12-port Serial-to-TCP/IP boxes that give us VISA connections at 2 IP addresses, 12 port each (so our VISA Open looks like TCPIP::172.18.110.1::8000::SOCKET, ...::8001::SOCKET, etc.).  We run each VISA device in its own Start Asynchronous Call "Clone".  The low-level VISA routines are, I believe, "functionally reentrant" as they don't retain State (VISA In and VISA Out), but in any case, we "wrap" them in our own "Open VISA", "VISA Read", etc. functions that we designate as PreAllocated Reentrant Clone.  Works like a champ (the original routine was written using LabVIEW 2011 and 2012 -- I've recently re-developed it using LabVIEW 2016).

Bob Schor

---

This is similar to what I have; nine clones of a preallocated reentrant VI started asynchronously, with each front panel in a subpanel on a different page of a tab control. All of the VISA calls (just Open, Write, Read, and in case of an error, Close) are in the same single "send command and receive response" subVI which is preallocated reentrant, then the more complex functions of reading operating conditions and writing setpoints are built on top of that (and all of those are preallocated reentrant as well). This worked fine when I was using the TCP functions instead of VISA, but the recent change to VISA made it run much slower, and as I said above it seems to be due to VISA Open (and possibly the others) apparently not running in parallel.

[Bob_Schor]

I Accept the Challenge!  [Easy for me to say, I already wrote the code ...].

We are "talking to" 24 remote Balances.  To test the Balances and the Switches, I wrote a routine that ran 24 clones of "Verify Balance", each with a different "Station" number (1 to 24) to make it specific for one of the Balances.  My "Verify" routine opened the Balance, started it spitting out weights, immediately reset, cleared, and closed the Balance, then exited.

I modified it so that it only did a VISA Open (using the TCP/IP call) and VISA Close.  I timed the entire cycle -- 24 loops to start the 24 Clones, followed by 24 loops to wait for them to exit, with the option to also change the 24 to 1 and time a single loop.

Doing all 24 takes about 500 milliseconds.  Doing just 1 take 80 milliseconds.  80 * 24 = 2000 (in "round arithmetic"), so I conclude that the VISA functions are at some level reentrant, or at least several of them can run concurrently.

Bob Schor

[Ben]

There was a bug in VISA back in LV 7.0 where all of the functions ran in the UI thread. That was latter fixed. But for me, I can only speak to the VISA read/Write and letting them run asynchronously.

Ben

[Bob_Schor]

OK, so I'm sloppy.  Just in case it might prove useful, I starting isolating the test code I'd used (and modified for the test mentioned in the previous post) in case it might be useful to attach here.  And what did I find?  Since this is a "real-world" piece of code, there are some additional "Wait" functions sprinkled around, specifically a 50msec wait in the VISA Open routine.

So let's assume that we can take 50 msec off the VISA Open, so the N=1 test of Open + Close now takes 80 - 50 = 30 msec, while the N=24 test takes 500 - 50 = 450 msec, 15 times longer than N = 1 (but still 15 < 24, so some overlap must be taking place ...).  However, if I had to guess, I'd guess the "Wait for Clones to Exit" code (hmm, what Timeout did I specify there?  Who remembers?  "You could look it up" -- and find -1, "Wait forever") is adding some of the extra delay for larger N.  Could easily be tested by having the Test Routine do nothing with VISA, maybe just call the Wait function for 30 msec ....

BS

[Bob_Schor]

Hmm.  Played a bit more, and am attaching my routines so you can "try it yourself".  Here is the top-level Tester.

The first For Loop starts 24 "Verify Balance" routines running as Asynchronous Clones, and the second loop waits for all of them to exit (the Wait has a Timeout of -1).  I can call this with N=24 or N=1.  The Verify Balance routine has an Open VISA (with the index determining which of the 24 Balances to open) followed by a Close VISA.  In addition, there is a Diagram Disable structure surrounding the VISA Open/Close so that I can make it "do nothing".

So here are some additional Timings (in milliseconds, eye-ball averaged) (you can try this yourself if you have the appropriate setup):

                        N = 24       N = 1

VISA O/C            400            17 (occasionally 500)

No VISA                60              7

So several things stand out.

• It takes more time to start and wait-for-stopping of 24 Clones than for 1 Clone.
• 24 Clones is from 3 to 8 (very rough math) slower than 1, but not 24 times slower!
• Even when doing N=1, if the Clone "does something" (like Open/Close VISA), the process can take an order of magnitude more time (the "occasionally 500" trials).
• When in doubt, write some test code and (as they say in Pittsburgh), "Check it ahht".

Bob Schor