LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

programatically delete a DAQ device

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.

0 Kudos
Message 1 of 11
(3,038 Views)

I have been working on this, and I just realized, that when I change the name of the devices, the tasks associated with those devices also have their names changed. I also seem unable to programatically change the physical channel that a task uses.  This means that my idea of changing the channel names isn't going to work unless I want to completely rebuild the tasks in LabVIEW, but then there is no point in even including MAX tasks at all, so that doesn't seem right.

 

Does anyone have a better way to solve this problem?

0 Kudos
Message 2 of 11
(3,027 Views)

I honestly just build up my tasks programmatically.  The application could check for supported hardware when it first runs and if there are multiple options allow the user to choose which device(s) will be used by your application (if you want you can save the preference in a config file so they only have to go through this once).

 

You can do just about anything that you could do in MAX programmatically via the System Configuration API.  If the user might have some other DAQ hardware though you'll want to be careful.  If you implement what I mentioned in the paragraph above it shouldn't be necessary to rename or delete devices.

 

I'm sure there are people who swear by using MAX tasks though and have success with this as well...

 

 

Best Regards,

John Passiak
Message 3 of 11
(3,011 Views)

Some of my coworkers don't use tasks either, but I just find they 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.

 

Anyway, I figured out a solution. I check to see if a non-simulated DAQ of the right type, and with the right name is connected. If not, then I just reload the MAX configuration file, which gets installed in the application directory. That sets up the hardware, and configures all the tasks with a single VI call.

0 Kudos
Message 4 of 11
(2,993 Views)

You are about 1/2 way there.  Yup the .nce can be added to the installer and this works well for cDAQ DAQmx and VISA aliases.  It does fall down on USB DAQ devices.  BUT, with USB DAQmx devices this works wonders

especially if you go to nirvana by building that code into an exe and following the link to configure NI Devmon to automatically run that exe when the USB DAQmx device is detected.

 

One of these days I should nuggetize that with step-by-steps and example vis to do the "regedits" programatically-  those regedit exes can also deploy and run from your installerSmiley Wink

 

In short- DAQmx stuff needs to be created once!  Preferably during development and exposed on the target in MAX ( if the deploy target contains no debug deployment -  use project Tasks if a debug deployment enabled target is specified untill MAX has context awareness for all those *.n[i]ce things) to aid system maintenance, integration and repair.  DAQmx MAX config support will also need to be added to your installer.

 

If the target is a medium or high- mix system (Lots of exe's) use the system API to load the *.nce so the next app doesn't overwrite your stuff.


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 11
(2,985 Views)

One more tip I forgot to mention.

 

During development keep your Tasks, and Scales in the *lvproj.  Why? Because they then make it to your SCC Repo as part of the *lvproj!  All developers can access them! and, they stay in synch.

 

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?


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 11
(2,982 Views)

@JÞB 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.

Message 7 of 11
(2,970 Views)

There's a nifty trick if you want to convert a MAX DAQmx task to a VI. If you right click on the DAQmx Task Constant there's an option to Generate Code >> Configuration which turns it into a subVI:

 

DAQmx task to VI.png

Craig H. | CLA CTA CLED | Applications Engineer | NI Employee 2012-2023
Message 8 of 11
(2,951 Views)

Thanks Jack.

 

That is exactly why I reached out for your thoughts!

 

I usually work with "One-off" systems.  Integration on one-offs is a key and yes MAX can help a lot!  My users are usually interested in just gettting that one or two off application working.   Yet, there are other use cases!  My advice is valid for only that percentage of developers that deploy to one or few-off targets. 

 

I suspect the number of % of users that deploy to "few-off" systems is high....... but the minority is impressive.


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 11
(2,944 Views)

@JÞB wrote:

I usually work with "One-off" systems. 


Very true; when volume is low (as low as one), ROI of any one arbitrary "software engineering best practice" could be negative. Our (infernal) task as engineers and business persons is to have a good grasp on the tipping points for each task.

 

I like using "happiness" as a heuristic; when either side gets sufficiently unhappy, it's time to change.

 


@Craig_ wrote:

There's a nifty trick...


 Slick!

Message 10 of 11
(2,939 Views)