Programati​cally delete a DAQ device

Question

I have created a system with hardware (a USB DAQ) and software that is to be installed on multiple computers overseas. I want to make the set-up as easy as possible because I don't think the people doing the setup will be very well trained, and I won't be there to fix any problems.  I have created an installer that includes all the hardware as well as software setup, but there is one issue left, and I'm not sure what the best way to solve it.  If the installer is run before the DAQ is connected, then the installer creates a virtual device. If the DAQ is then connected, it is named Dev1, which doesn't work with any of my tasks, of course. I have some code that runs, and verifies the hardware set-up each time the system is started, so I can see if the device with the proper name is virtual, and if so, I can rename the actual and virtual DAQ device to the right names, so my tasks operate properly. However, I now have a virtual device hanging out on my system doing nothing, which I would like to avoid, because there is an outside chance that I will end up on the phone trying to explain to people how to straighten out a system when it goes bad, and I want to keep it as simple as possible.  I have two questions:
Is there some way to delete the virtual device programatically?
Is there some better approach to accomplish what I am trying to do? I thought about not allowing the installer to proceed if there is no DAQ device plugged in, but I don't know if that is possible.

Answer 1

Jeff·Þ·Bohrer wrote:
Hmmmm...... There has got to be a way to script up the "Toss Tasks to MAX" and "include .nce" as part of a "Deploy" process. Wirebird, Jack?  any opinions on that?
I would tend to agree with John_P1's quote below:
John_P1 wrote:
I honestly just build up my tasks programmatically.... You can do just about anything that you could do in MAX programmatically via the System Configuration API.
 And I would tend to shy away from:
Jo-Jo wrote:
...I just find [that using MAX] really speed development, and help with maintanence because you can test out all of your tasks in MAX outside of any LabVIEW code. And debug and toubleshoot hardware without using any of your own software, so you know any problems are not software bugs.
 once going into production. MAX tends to be a good tool for getting your feet wet after unboxing the hardware, but something you gradually migrate away from after the prototyping phase -- yet occasionally return to, as you mention, if you need to back up to square one for new prototyping or as a sanity check.
It's possible to deploy NCE hardware behavior configurations, but not necessarily desirable. For the same reason it's possible to deploy any arbitrary configuration (INI, XML, ....), yet it's likely more desirable to build this configuration programmatically -- perhaps persisting it to disk if it's a user-modify-able configuration, or if it's desirable to persist user settings between subsequent deployments -- else it might be most desirable to keep the "configuration" hard-coded as essential business logic (as DAQ tasks might tend to be).
Though, it sounds like you have a solution, and that's far more valuable than more work! Keep a tally on whether the current deployment strategy keeps you and your end users happy, and if so, keep it! Else, consider John_P1's advice, which is more likely to scale with your application if things get hairy.
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}