Strange VISA session behavior/what is the implementation of VISA close for VXI-11 instruments?

[marshaul]

I have an instrument (an MPI ThermalAir TA-5000) which has been... finicky when it comes to communication for as long as we've had it.

I recently decided to remove VISA open/close completely from our main program. This created no problems for any instrument except the TA-5000, which now refuses to talk to any second instance of a program which communicates with it. 

I spent quite a long time messing around in order to make the following observations:

1. Without explicitly using VISA open, sending a single communication to this instrument causes it to become "locked" to that process. That process may continue continue to communicate with the device, but no other can.

2. Upon issuing VISA close in the first process, a second process may attempt to communicate. This will fail the first time, but succeed the second, whereupon the instrument is now "locked" to this second process. 

3. No other VXI-11 instrument we have exhibits this behavior. They all may communicate freely with multiple parallel processes without using VISA close (or open). 

I am going to communicate my findings to the manufacturer of the instrument, but in the meantime I am going to work around it. Unfortunately, the best algorithm I can think of is:

1. issue VISA close after every single instance of communication with this device.

2. Implement a retry loop for every single write-read

I'm curious, however, what exactly goes on behind the scenes with VISA close and VXI-11 instruments which could cause this behavior. Perhaps I could come up with a more elegant solution, or at least a more direct way of determining whether this instrument is "locked" to another process than by failing to write to it (which could have numerous other causes). 

[marshaul]

When I encountered discussion about VISA open and close being unnecessary, I did not read that auto-opened VISA sessions are left open until the application instance terminates (or the VI finishes execution in the development environment and the "automatically close VISA sessions" option is selected).

Since I learned this, it resolves part of my problem. 

I have since been able to determine that the problem I had was twofold: VISA sessions left open (they need to be closed when parallel applications may need to talk to the same instrument), and my instrument refusing the first attempt to write (returning error -1073807343) after a VISA open, whether the VISA open occurs explicitly or implicitly. Arbitrarily long delays do not resolve this issue. 

So, I could write a special communications wrapper for this device, prepending a VISA write of some junk string to every sequence of write/read operations before closing the instrument out again, but now I'm curious about what happens under the hood for a VISA open of an LXI-11 instrument, and whether there's a more elegant solution to my problem that writing junk strings with a short timeout and discarding the inevitable error.