LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best practice for device identifier in a deployed application ?

Solved!
Go to solution

What is the best practice to ensure that a daq device identifier remains valid in a deployment ?

I have a VI where the daq device is set to DEV1, but in the target machine(s).. well to be honest I am not sure. Windows reports it as USB_6009.

I could install MAX on the targets and (manually) fix identifiers that way

I could programmatically ascertain the connected devices and use that to base a selection

Is there a better solution ?

LabVIEW 2015

0 Kudos
Message 1 of 4
(2,804 Views)
Solution
Accepted by topic author JPP

There are different things which people do in such cases. Personally, I prefer to use the DAQmx device query. Your application should always have a kind of Idle and Init state with some other states in a form of state machine. When the user launches the installed application or Exe, it goes into the Idle state. Here the app lists the discovered DAQmx hardware present. Either the app automatically selects the appropriate hardware, or gives a selection option to the user. After this step, the app initializes the HW and creates the named reference.

 

Using the DAQmx HW identification functions, you can even check the unique ID  (serial num) of an NI device. Once I programmed an application where lots of identical HW type was used on the same rig. I hard coded into the app which channel(s) belong to which ID of the connected many same type of NI hardwares. In the future, if one of them is broken and get replaced, of course a new ID is needed to be assigned to certain task/channels, but this info can be stored in a config ini file.

 

A configuration file is always a good idea: when the user launches you app, the app can ask the user whether to load the HW settings which were used during the previous run, or she/he wishes to create a new HW config....

Message 2 of 4
(2,766 Views)
Solution
Accepted by topic author JPP

I agree with Blokk.  I just wrote a routine for a prototype that has a USB-6009 hidden inside.  My code starts with a DAQmx System Property Node to get an array of Device Names.  I feed this to a For Loop, where I feed each Device to a DAQmx Device Property Node (as the Active Device) and inspect the Product Type and the Device Serial Number.  This way, I can tell if my "known" USB-6009 is present (and can then run code specific for that particular Prototype device), some other USB-6009 (and run almost the same code, but knowing this is not the "real" prototype, so I need to simulate some things in LabVIEW), or no 6009, giving me a choice to simply exit or to go whole hog with the simulation and have code that "pretends" there's a USB-6009 and make up "fake data".

 

Bob Schor

Message 3 of 4
(2,741 Views)

Thank you,

 

have used ideas from both those solutions to implement a solution.

 

0 Kudos
Message 4 of 4
(2,697 Views)