Find VISA resource

[J.Mamakos]

I am having trouble finding VISA resources properly. I have no problem detecting instruments that are connected on the GPIB but after they've been detected once LabVIEW is convinced that they're there for ever more, even if I unplug and disconnect the instrument! The only way the list of connected instruments is reset is by completely exiting LabVIEW and rebooting it. Why is this?

I am using LabVIEW 6.1 (though that may not make a difference) and I have attached a VI with two different ways of detecting whether any of four possible instruments are connected. The SubVI is used to give a command to one of the instrument and this is capable of returning an error if the instrument is not connected, whatever the situation. How can this detect the instrument as expected, but the other methods not?

In this VI, I need to detect how many, if any, and which out of four possible instruments are connected. Simple, yet surprisingly difficult! 😞

Any help please?

James

[J.Mamakos]

*POP*

...to the front again...!

[Dennis_Knutson]

Pop?

If you want someone to look at your code, you better not attach VIs with the block diagram removed. Besides, I'm not sure what the question is? What is wrong with querying the instrument to see if it is there?

[smercurio_fc]

Unfortunately, you seem to have saved the VIs without a block diagram, so I don't see how useful they are. 

My guess is that you have a hardware issue or perhaps a driver issue. What are you using for your GPIB controller?

[J.Mamakos]

My bad! Here it is again.

Basically, I have an application which can/will conduct different tests which each use different instruments (each instrument has its own GPIB address). Before each new section or test is started i want to detect which instruments are connected and switched on, and if any of the ones needed for the particular test are not detected then an error (pop-up window) will flag up.

The problem I am having has also been verified on other machines (and applications) where we are trying to implement a similar function.

I find that after an instrument (any instrument) has been detected on an address, LabVIEW will not then be able to tell if it has been disconnected (which is a likely scenario). It appears that in both the attempts I made, I get the same result. For example...

Using the VISA Find Resource function, I run the VI with 4 instruments connected. It finds all 4 and identifies which addresses they're on. If I then disconnect any/all of the instruments and run it again, it still says that they're all there. The only way I can make it 'forget' that the instruments had been found before is to completely restart LabVIEW.

The same problem occurs if I search every address to see if any instruments are present. Once found, they won't go away.

However, the subVI controls one of the instruments and if the instrument isn't present then it fails.

Any suggestions?

[Dennis_Knutson]

The VISA resources are not updated constantly - at least not in 6.1 and I don't think current versions do eother. If you really have a situation where you allow the instruments to be unplugged or powered down (and why do you think this is likely?)after you start the program, you need to send a query to each one. A simple *IDN? (like what is done in an initialize function) is sufficient. An proper error handler in the program could also work instead of a query process and would be more robust. If the instrument could be unplugged or powered off prior to the test, why couldn't it be unplugged/powered off once the test starts. Always check the error cluster and the code and go to an appropriate state. The use of a state machine architecture is your best option.

[JÞB]

"Ah - Interesting"

What is the selection if you look at "Tools>Options>Misc...>Automatically close VISA sessions? I know a lot of improvements were made to the VISA functions by  LV 7.1 (one of the reasons we moved to it years ago)but I recall that we encountered problems related to this.  I seem to remember that in 6.1 available resources were loaded at LV initialization from MAX and although you could add a new resource you could never destroy it while the app instance was running.  

Version 7.0 added the ability to "refresh list" from a VISA Resource control's dropdown selection menu.  I always considered the lack of this feature to be a bug in earlier versions. 

[smercurio_fc · Accepted solution]

Well, now what you're saying is starting to make a bit more sense. I misunderstood what you were asking before.

---

Jeff Bohrer wrote: What is the selection if you look at "Tools>Options>Misc...>Automatically close VISA sessions? 

---

From the Help: "Automatically closes VISA sessions left open by the application when the top-level VI becomes idle. This checkbox is unchecked by default." This was added at some point (don't remember when) and the default was True. It caused a lot of heartaches and bitching from users (I was one), so NI changed the default to False.

As Dennis pointed out, there is a distinction between the resource and the instrument. When you do an initial scan the resources get created. There is no mechanism that automatically detects that an instrument is no longer there. In fact, when you scan for instruments in MAX, it's sending out *IDN? queries to find instruments. Thus, you have to check for the presence of an instrument by actually trying to talk to it. 

[J.Mamakos]

Yep - sending *IDN? to all the channels in turn works just as I expected the VISA Find Resource to work. Thank you for the tip. 🙂

[Brian_L._Bowers]

How does this work for USB raw devices? My device is not an instrument and so it does not respond to the *IDN? query but it still is recognized in MAX as soon as I plug it in and it is removed as soon as I unplug it. So MAX is somehow being notified that the device is connected or disconnected. I need this functionality in LabVIEW to know when my device is unplugged. The VISA Find Resource works fine to detect the connection but it doesn't work to know when it is disconnected. It is not efficient to use communication to determine if the device is present or not because the communication protocol is not written that way. It assumes that the transport will notify when the device is connected or disconnected.