VISA open seems to prevent other visa operations.

[Taylorh140]

I have seemed to observe that when i have multiple devices communicating via visa in separate loops that the visa open will pause concurrent reads or writes on other threads. I have an architecture that tries to re-establish communication after a device error has occurred and this sometimes causes timeouts on unrelated devices due to the visa open preventing communication to other visa devices. Has anyone else observed this? Is there a simple fix that i don't know about? Really anything is helpful, thanks.

[TheOtherKid]

Is this happening in LabVIEW?

When you say other threads do you mean concurrent loops or are you manually selecting the thread each runs in?

How many devices are you working with? What types of devices are they/what communication method do they use? Does the stall change depending on how many devices you have or which device is being opened?

What is the device error that you are trying to work around?

[Minions]

Are you using a common bus structure like GPIB?  If you have two or more instruments on a common bus like GPIB, it stands to reason that it will only allow access to a single instrument at a time.

Post your code such that we might help you further.

[Taylorh140]

I had a little bit of time to put together an example here. 
Yes, I am using labview.

Yes, I have multiple instruments on a single bus but it is Ethernet.

The main problem is that Opening an VISA connection can cause other visa devices that are acquiring data to pause acquisition and this causes:

A- confusion of the source of error.

B- difficulty getting multiple devices up and running.

A note on the example is that the TCP pallet is unaffected during VISA opens. However reads are delayed until VISA open times out as can be viewed in the example. 

[JÞB]

Can you explain a but more about what you are seeing in the vi?

I observe that you are opening 127.0.0.1:5054 as both a TCP/IP Listener with the TCP/IP API and additionally as a VISA I/O Session :Instr Class.  This makes very little sense. for multiple reasons.

First, unless you Have separate ethernet cards DON"T DO That! the input buffer is the input buffer and there ain't no second buffer  But, you cant address seperate ethernet cards since String to IP Address is not set to multiple output (Read the help) so it will only find "TCPIP0::127.0.0.1::5054" and the VISA I/O Session string is also "TCPIP0::127.0.0.1::5054"  

Second, The VISA Session is of the wrong class.   Use "I/O Session.TCPIP Socket" not Instr.  Instruments are for instruments not services.  (Unless you have an instrument at which point the TCP listener is the mistake)

[Taylorh140]

First, thanks for having a look at this. I may have some errors in the code but the goal here is to show some behavior on the (VISA open) function. This VI was intended to be an example of 3 separate devices.

Device 1:

The top loop is intended to be a device that cannot be found. The connection is intended to be open but is simply not there.

Device 2:

The next two loops are the visa example. The only thing that is intended to be noticed is that when device number one is being opened device number two cannot read. The top vi is the code associated with reading. The lower is an emulated device that only send the current timestamp.

Device 3:

The last two loops use the TCP pallet to show that the it is still possible to read using the TCP pallet even when the VISA open is being called.The top vi is the code associated with reading. The lower is an emulated device that only send the current timestamp.

I feel like you are saying that there is only one receive buffer for all reception from a Ethernet phy.

[Taylorh140]

Also does it actually matter what class the VISA resource name constant is set too? I thought that if the string was a TCP/IP socket it would produce a TCP/IP socket class upon opening the VISA resource. The loop-back addresses for each device is different so there should be no shared buffer between them. Most of the TCP code was based on the simple tcp example project. Either way the behavior that I'm trying to point out is the non-rentrant nature of visa read when visa open is called and before it times out. When the try to open is enabled the read pauses for 1 second every 2 seconds

.Visa Open pauses reads.

[JÞB]

Lets clarify one point first straight from the Help file: "By default, the VISA resource name control is set to the Instr class, which also corresponds to the class of the session to be opened. You can change the class type by right-clicking the control in edit mode and selecting a different class from the shortcut menu."

Now, mixing TCP and VISA on a LOOBACK RESERVED Address that short circuits at the IP portion of the Network layer is just a bit beyond my understanding of how ANY data is received from the remote device (you should only be receiving what you send unless the TCPIP stack is hosed.

What devices are you connected to?

[Taylorh140]

I'm not connected to devices, they are simulated representations of devices so hardware is not necessary to reproduce the issue. 

I have a theory of what might be causing the issue. I theorize that the VISA Open function is non-rentrant, I also theorize that the "VISA Read" or "VISA Write" might internally call VISA Open. That is possibly why my second device see (VISA Issue (1).vi) halts reading while "VISA Open" is being called for device 1.

[JÞB]

---

@Taylorh140 wrote:

I have a theory of what might be causing the issue. I theorize that the VISA Open function is non-rentrant, I also theorize that the "VISA Read" or "VISA Write" might internally call VISA Open. That is possibly why my second device see (VISA Issue (1).vi) halts reading while "VISA Open" is being called for device 1.

---

No, VISA Open has a default "Duplicate Session" Value.  it will use the open session if such a session exists.  Consider putting the session on a SR. And using it (the session is currently dead code and the compiler wight be dumping it.  Have you checked the error out of the VISA Open?  Letrs stick some probes in there on the outputs and look since the top loop is dead except for the notifier Ref which is in turn down stream dead code.