Programmatically Finding Connected cDAQ Units

[Lbee11]

I've currently got a solution to my problem, but it's not very efficient! I have a single laptop that can connect to 12+ cDAQ units by Ethernet cable (local only, the cDAQ's aren't on a network). I'm currently using the below snippet to try and reserve the chassis to detect if it is present, if it isn't move on to the next one, if it is, output the now reserved chassis name to be used elsewhere. Whilst this solution works, and it works every time, if I plug in to the 12th chassis, I have to wait for every single Chassis before to attempt a reservation:

Is there a better way of doing this? It takes about 8 seconds for MAX to try and reserve a cDAQ before the error is created, nearly 2 minutes for the 12th cDAQ to actually get reserved.

I'm thinking that if this is the best way of doing this, then I'll at least write the cDAQ name to file and try it first next time before starting looping as I can't have the end user waiting for so long everytime they wan't to connect to their machine.

Thanks

[OEM_Dev]

Take a look at this example

https://forums.ni.com/t5/Example-Programs/Search-and-Find-Connected-DAQ-Devices/ta-p/3517322

[Lbee11]

This returns information even if the cDAQ is not contactable though. I only want to know what device is physically connected, not just present in MAX

[OEM_Dev]

Really? On my system it only returns simulated or connected DAQ devices. I only have USB units, not network so maybe that changes things...

[Hooovahh]

I wish this were easier.  At the moment I set static IPs and I will just ping them with some code I wrote and if they respond I know it is a controller.

https://forums.ni.com/t5/LabVIEW/Discover-cDAQ-Ethernet/m-p/2817584#M824878

This is because querying MAX or some system information can some times hold previous information caching it to where it states hardware is there when it isn't, as demonstrated in that thread.  That was a few years ago and DAQmx drivers might have been improved.