How can I programmatically generate and use a reference to either a local (USB) or remote (Ethernet) cDAQ chassis module channel in an app?

[Confuzed]

Here's the problem... 

Our lab has quite a few USB cDAQ chassis, but someone recommended we start using Ethernet cDAQ chassis instead (for a variety of good reasons).  We purchased an Ethernet cDAQ chassis but it won't work with any of our existing apps because the apps reference the chassis by the NI-MAX generated name (i.e., cDAQ1), but NI-MAX will not allow us to name the reserved Ethernet chassis cDAQ1.  So, all the calls to things related to cDAQ1 fail. The thing that I'm trying to avoid is putting calls to NI-MAX named resources in my code (since I can't be sure which local or remote cDAQ chassis they'll be trying to use).

So, moving forward, I was wondering if there's a recommended best practice or design pattern for handling this type of scenario.  I'm thinking that the way to present a list of discoverable cDAQ chassis to the user (i.e., USB if present, and/or Ethernet if available) that the user could select from would be the DAQmx Device Name constant as a front panel control, and the app could then use that to then programmatically generate a DAQmx Physical Channel constant for, that all of the DAQmx measurement task calls could then reference. 

I know I could put a Physical Channel control on the front panel for a VI, and let the user pick which channel on which module on which chassis NI-MAX is aware of, but there’s 8 modules in our cDAQ chassis and many things connected to each module… and I don’t want the user to have to select/configure every measurement in the app every time they start the app. That’s too much work.

What I’d like to do is put a DAQmx Device Constant control on a front panel so that the user could pick a device (i.e., a particular local or remote cDAQ chassis) and then programmatically create a Physical Channel Constant based on the Device Constant they selected with the known module and channel number (because all these cDAQ chassis use the same modules and are wired to the same things (thermocouples, voltage inputs, etc.)), and then use that Physical Channel Constant (or rather, Physical Channel Variable, if such a thing exists) with the DAQmx Create Channel vi to create the measurement tasks.

So… the $64,000 question is… is there something like a DAQmx Physical Variable (not Constant), that would allow me to do this using the DAQmx Device Constant (and known module and channel number)? Is there a way to create the physical channel constant variable programmatically, maybe like concatenating strings and turning that into the physical channel constant variable using some other vi or something?

Can anyone point me to an app note, example app, or something that describes/shows how this can be done? If not, can anyone offer any suggestion for how this type of problem is typically or best solved?

[Confuzed · Accepted solution]

Well, after looking at lots of help file info I found a note that said you could wire a string into physical channel inputs.

So, I concatenated the DAQmx Device Name control output and "Mod5/ai0" (into a pink-ish wire) and wired that into the (purple-ish) DAQmx Create Channel VI "physical channels" input and it worked.  A little pink-ish dot showed up at that connection point, which I think is some kind of type-casting warning indicator.  If I wire a "real" physical channel control to that input the little pink-ish dot disappears.

Problem solved, well... sort of.  To move forward I'll have to edit many DAQmx Physical Channel Constants this way to use the selected DAQmx Device Name, in many apps,... but there is a way to move forward.  It's just going to be painful 😞

[Kyle97330]

I know you marked this as "Solved" but just a FYI, here's how I prefer to do it:

You can use that to determine which devices your system detects to make sure they're all present, and then get all the references to the lines/ports/channels that you need programatically instead of with hard-coded constants you type in.

[Confuzed]

Thanks.  That looks like really useful info.  I'll try to take advantage of it.