VISA find resource issue

[DeepSpace]

I am automating a manual test process in LabView and using VISA Find Resources to identify the com port for the device-under-test (DUT) so the operator does not need to enter the COM port manually.

The output of the VI (the COM port # for the DUT) is then passed to another VI that sets up the serial port parameters.

It works fine the first time, but when I run the VI again, the DUT cannot be found by VISA. When powered up, I can see the DUT in Windows Device Manager every time. So, I know it is enumerating correctly.

The strange thing with VISA Find Resources is that when I power down the DUT after the first run--and the DUT no longer shows in Device Manager--if I click the control to select the VISA resource in my VI, it still shows up in the list even though the device is not powered up.

When I try to run the test again, I get errors because VISA cannot find the device even though it shows up in Device Manager and the correct VISA COM port is selected in my VI.

When this happens, the only way to get this to work again is to close LabView and restart everything. Once again, the VI will run fine the first time, but after that it no longer runs and VISA cannot find the DUT.

This may an issue with VISA Find Resources. I did search the knowledge base but could not find anything about this issue.

So, I'm looking for any input on this issue to see if there is a work around or, if I'm just not using VISA Find Resources properly. My VI is shown below.

The string filtering is just to extract the COM port number from the DUT string returned by VISA Find Resources.

Thank you for any input on this.

[Kyle97330]

If you do a search in the forums it seems that this has come up before, but never with a great resolution.  It looks like there is no way to cause VISA to refresh its list properly without going into NI max and doing a right-click "Refresh" or pressing F5, which is probably what you need to do here.

The only thing I can suggest is the following:

• On the first pass, do what you do now to find your "ELMO" port, but instead save a list of all ports that are NOT "ELMO" ports.  This will give you a list of things that you know you can't use.
• On subsequent passes, generate the name of the port programmatically just using integers starting from 1 and counting up, but skip the ones you know from the first pass are standard ports.  Try a VISA open on the rest.  The first one that works, assume it's your new device.

[DeepSpace]

Hey Kyle97330

Thank you for the feedback. It's a bit frustrating, but it is what it is. Thanks for the suggestions. They are worth looking into.

Regards,

[DeepSpace · Accepted solution]

For anyone who is interested, I've resolved  this issue. It was my oversight that caused the problem. From the output of Find Resources, I type cast that into a VISA reference to pass to a property node to get the information that I needed. The problem was simply that I did not close that reference with a VISA Close.

Once I did that, everything worked as expected.

Don't forget to look at the simpler solutions first.

[billko]

---

@DeepSpace wrote:

For anyone who is interested, I've resolved  this issue. It was my oversight that caused the problem. From the output of Find Resources, I type cast that into a VISA reference to pass to a property node to get the information that I needed. The problem was simply that I did not close that reference with a VISA Close.

Once I did that, everything worked as expected.

Don't forget to look at the simpler solutions first.

---

Thank you for being gracious enough to offer your solution.  It's not easy to admit an oversight, let alone highlight it as the solution.