Thanks for the detailed explanation. I think the "Is Not a Number/Path/Refnum" is what I'm looking for based on what you mentioned and what the probe has under the hood. I've never really had a need for using it before with VISA until now and I'm learning things even after many years of coding LabVIEW.
What brought up the question was a situation where two separate "instrument drivers", one an Keysight 973 multiplexer and the other a Pendulum CNT-91 Frequency counter were being called in separate loops. The loop for the Keysight 973 was setup to periodically (every 10secs) sample its channel list, the loop for the Pendulum was setup in a similar fashion to sample every 500ms. At some point the end user disconnected the Keysight 973, but wanted to continue measuring with the Pendulum CNT-91. But with the Keysight disconnected, the VISA calls in its loop were locking up or reserving the USB bus and interfering with the measurements in Pendulum loop.
Diving into the weeds of the code, I noticed:
the Keysight 973 driver (actually an older version using Agilent 34970 code) had Synchronous VISA Write and Read calls. So I thought those must be running in the UI thread and blocking the execution of the Pendulum loop when the instrument was connected. After switching them to Asynchronous VISA calls the problem persisted.
Both VIs that sampled the data were had VI properties for Execution set to "same as caller" and since they were both called from top level VIs that had property nodes, event structures etc they were probably both running in the UI thread. I switched the Keysight to the "data acquisition" thread and the Pendulum to the "instrument driver" thread. But the problem still persisted.
in the Keysight loop I had made use of the VISA User Data property to store and track the number of channels were being queried. This VI was taking ~2secs to execute when the Keysight was not connected. This was a surprise to me because I thought it was just a passive property node that would return its value (quickly and without error) even if the instrument was disconnected. But apparently, its doing much more under the hood, possibly even trying to reconnect (possibly VISA open under the hood?) to the Keysight instrument. After temporarily disabling this code and all instrument query in the 10 sec sampling loop, the interference or blocking of the Pendulum went away.
Lessons learned:
If an instrument is disconnected physically, make sure you disable any queries to it if the VISA session isn't valid or didn't' connect properly in your initialize state. I'm still not sure why a VISA query timeout or User Data call would block a separate VISA loop with a different address from executing if they are properly setup to use separate threads (maybe I'm still not doing that correctly). I guess I could use NI I/O trace to get more details about what's going on under the hood when the User data property is read. What's also weird to me is that the VISA timeout for that session was 10 seconds (not 2 seconds) but every call to the User Data property took almost exactly 2 secs.
Avoid using the VISA user data property for passive storage because its not actually passive.
the "Is Not A Number/Path/Refnum" works with VISA sessions. Even though I disabled sampling now if the Keysight initialize state fails, I'm also using the "Is Not a Number/Path/Refnum" as a paranoid check before executing the sampling code now. Looking at the VISA probe VI that Darren linked to, it appears like the code also checks the VISA property "Rsrc Class" to see if the VISA session "Is Instr" if the "Is Not a Number/Path/Refnum" returns a False. Does anyone know if this is a passive call under the hood?
Thanks for everyone's help.