Multiple cDAQs with the same IP

[obsessed]

Good Evening

I have currently built a test box with a cDAQ 9189 chassis as the backbone.  The test box uses a dedicated laptop to help process and display all the data.  Nothing overly complex here.  Ideally we would like to ramp up and build multiple test boxes with multiple laptops.  I would also like to make it so that any box can go with any laptop and not have any reconfiguration.

I have tried a couple time to do this without success.  I have been setting each box up with the same static IP address.  Each Laptop also has the same static IP address.  MAX did not like this setup the instant it put the second box with the same IP  address in.  I then changed gears and tried to do all the channel configuration programatically.  Again I ran into errors.  

In general is what I am describing in the first paragraph possible with multiple cDAQ chassis's? To summarize I'd like to end up with multiple laptops, all running the exact same code that can then function with any number of "field test boxes" that each have there own cDAQ 9189 in it?  If someone has accomplished this kinda of thing and coul get me started down the right path I'd greatly appreciate it. 

Many Thanks

T

[rolfk]

I hope you don't mean to use all those cDAQ with the same IP address on one network. That definitely never will work!

If you are not doing that what is likely your difficulty is that for NI hardware in general, it's not only the IP address that identifies a device but also its serial number. And that is a feature not a bug! 🙂

That said there is some functionality in the DAQmx palette that lets you discover DAQmx network devices and then you can go from there. It's a bit cumbersome to use and get to work across different systems but I have done it in the past using functions like DAQmx Add Network Device.vi, DAQmx Reserve Network Device.vi, DAQmx Unreserve Network Device.vi and DAQmx Delete Network Device.vi. 

Once you found the device node with Add, you should Reserve (lock) it and then do your thing with programmatic task access (I never use the DAQ task configuration in NI-MAX and always access the DAQ hardware programmatically) and at the end Unreserve it and optionally Delete the device. Unreserving it is important as otherwise the device will refuse another client to use it.

[Bob_Schor]

As an alternative to Rolf's clear (and logical) explanation that if your PCs and cDAQs are both connected to a network, then the DAQ (and the PC) IPs need to be different.  

So don't connect them to the network, but connect them "directly" to the PC using a "cross-over" cable (or, much better, purchase an inexpensive 4-port router, cost was around $30 the last time I looked, a decade ago) and plug "directly" from your PC's ethernet port to your cDAQ ethernet port.  Of course, this means that your PC needs a second NIC if it also wants to be connected to "the network", so this is more readily accomplished with a desktop PC than with a laptop.

We've used this technique for collecting data from LabVIEW RT systems based on PXI boxes.  We abandoned cross-over cables in favor of the inexpensive router/switch, as it was much easier handling two "regular" ethernet cables (no chance of making a mistake, easy to get replacement cables, multiple lengths easy to get).

Bob Schor

[obsessed]

Thanks

No I did not mean multiple test boxes (and cDAQs) on the network, at the same time with the same IP. 

I meant One computer connected directly to the cDAQ, but I want to be able to swap the cDAQs without changing anything in either the program or the cDAQ.  I am not at my computer right now so I can't give you the exact error code it is currently giving me.  

When I did the prototype for this box I configured it in MAX.  Is it possible that if I don't delete the configuration in MAX that I won't ever be able to get Rolfs method to work across multiple boxes?  Rolfs method always works fine with the original box, but now when I try the second box and setting it up as Rolf described I am getting errors (Rolfs method works fine when plugged into the first original box)

Thanks

T

T

[obsessed]

Would using a cross over cable vs a regular cable matter?

[crossrulz]

---

@Bob_Schor wrote:

So don't connect them to the network, but connect them "directly" to the PC using a "cross-over" cable (or, much better, purchase an inexpensive 4-port router, cost was around $30 the last time I looked, a decade ago) and plug "directly" from your PC's ethernet port to your cDAQ ethernet port.  Of course, this means that your PC needs a second NIC if it also wants to be connected to "the network", so this is more readily accomplished with a desktop PC than with a laptop.

---

Many NICs have the capability to automatically do the crossover for you.  So you don't really need the crossover cable.  I do this all the time with a cRIO; I just directly connect to a cRIO with a standard Ethernet cable.

[rolfk]

---

@obsessed wrote:

Would using a cross over cable vs a regular cable matter?

---

Nowadays usually not!! Almost all Network PHY interfaces support automatic MDI/MDI-X detection and adaption as well as automatic speed negotiation. But that was not always like this and some chipsets had serious problems to do this properly in the past, fighting with the remote side about who should cross the signals and how.

So if you have fairly new hardware (<10 years old) you should be fine without any crossover cables. But as always your mileage may vary. With old devices and/or faulty firmware, this could be definitely not always true.

I never have any configuration in the NI-MAX view beyond what NI-MAX finds itself automatically. Definitely never use preconfigured DAQ tasks in NI-MAX but always use the DAQ hardware directly using DAQmx calls. 

[Bob_Schor]

Well, I confess I started hooking up PXI boxes to PCs about 15 years ago, and learned (by sad experience) about Cross-over Cables and How to Tell If You Had One.  Drove me crazy, then I bought "hardware to do it".  Haven't been near one of those older systems in at least 5 years, and it doesn't surprise me that "modern" NICs can "figure out" which line is which, obviating the need for worrying about the Cable.

Bob Schor