Rolf, very true indeed, however you are speaking in real terms, and not the fantasy land I like to live in as much as possible! 🙂
Long shot, but is the exe blocked?
Under some circumstances (when downloaded or sometimes when copied from a network) the exe is blocked by Windows. You have to right click, properties, and tag 'unblock' (unlock?) to make it work.
The .exe opens & runs (after entering admin creds). I have a warning popping up to the user alerting them that the DevCon code may not have run, but they can continue the test, and the rest of the test works fine. The Bluetooth Dongle we are using is very finicky & would become unresponsive randomly. I added DevCon commands to disable / enable both the dongle & p.s. before every unit is tested. I did not want the failure of DevCon to abort the test however since the dongle failures are so random. The tester would have to always physically remove & then re-insert the dongle when they saw VISA errors during the test. I just automated this process using DevCon. So basically the only thing that stopped working was the DevCon command I am feeding to SysExec to call it. I now get an exit code 1 and an error when DevCon vi runs.
The exit code 1 clearly indicates that DevCon itself runs into a problem and that has nothing to do with LabVIEW itself. So what happens if you execute the same devcon command from a command line? You need to get this working in the command line before you can continue with LabVIEW for this. LabVIEW is only the messenger, telling you that your utility you wanted to call failed but it can’t do anything about that.
What you said above is exactly my understanding. I was hoping someone here was using DevCon in a similar way, ran into the same issue, and determined the root cause. I am looking into what has changed in the OS of these systems to block the DevCon commands. I will see if they will run from the cmd line.
Your use case of disconnecting devices because they can operate flaky, while not totally unique, is seldom enough that chances that someone else is using the same type of device AND has run into this in only the few months since this seems to consistently occur on your systems AND was able to solve it AND is reading this forum AND is able and/or willing to offer his time to help you, is small enough that it is highly unlikely.
I'll jump on this late..
I've used Devcon in the past - It's not 100% reliable. The only 100% reliable method I ever cam up with was to build a piece of custom H/W.
USB>Serial device which takes commands and enables an opto-isolator.
Isolate USB Power lines
Isolate USB data lines
(ensure you connect data before power and disconnect data before power to prevent any issues)
build a custom box to do the above an talk to is over VISA session.
only connect device when told to by serial coms (drive to connect, default is open circuit)
You use another USB port, but you remove any driver update / permissions issues entirely. - as you've basically simulated a manual connection and remove.
You can buy HW that acts similar as well:
Capable Robot - Products | Programmable USB Hub (<this one seems a lot of fun)
The HW won't be as cheap as DIY (<20$ I suppose), but you'll safe hours (or days). Depending on your HW skills, a off the shelf device might look more professional.
James & Wiebe,
Thanks for the HW suggestions. That may be something we pursue down the road, but I would like to keep the functionality inside of my LabVIEW app if I can for now.
We are constantly running into issues with our many many LabVIEW systems that range from the newest HW to some 24+ year old systems, every time IT performs OS or security updates. The DevCon code is attractive because it is re-usable & has worked great so far (until it didn't)!
You know that "shouldn't" is not equal to "isn't"?
Any sentence containing should or shouldn't can end up being the famous last words! 😀
See below for an example of famous last words.