Two E1.31 controllers with same IP and Universes

[nato595]

What will happen if two pixel controllers on the same E1.31 network have the same IP and same universe config?
Will they both do exactly the same thing, or will all the data go to the first controller it finds and ignore the other, or something else?
Unicast vs. Multicast make a difference?

Basically I'm contemplating setting up two identical props (megatree for example) and rather than using up twice as many IPs, universes, and lines in my sequencer, I'm hoping I can just program one and the other will be a clone.

 

[David_AVD]

You can't have two IP based controllers with the same IP address on the same network.

You can however set them up with the same universes. I do this in my display.

 

[keithsw1111]

Yes you can but you must use multicast.

 

[scamper]

Are the props too far apart to just double up on each output. Because you could try that.
Otherwise there is no problem with running as many controllers as you want on the same dmx channel. The controller doesn't know what else is going on, it just see's that it wants that piece of data and uses it.
I wouldn't worry about ip, you have more than enough choices.
I would love to see the display if anyone managed to use every available IP address, universe and dmx Channel. Or be it with welding goggles ;-)

 

[multicast]

What will happen if two pixel controllers on the same E1.31 network have the same IP

This is a great question. Theres a few things to consider here.


At an IP level, having two devices on the same network is *generally* a bad idea, [ unless you really understand why you are using the same address twice, then dont' go there. ] Lets see what happens;

When your controller ( thats the thing that wants to send data ) wants to *send* data it needs to work out which device ( the thing receiving the data ), it has to do a couple of things. It has to work out where to send the IP packet.

On an ethernet network every device has a MAC address as well as an IP address. The mac shoud'tn normally change and should be globally unique ).. In order to find out which MAC address the IP address gets delviered to, it does something called an "ARP Request".. The ARP is *broadcast* on the network so *everything* hears it.. If a device is using that address, it then replys and says Its me.. The controller ( the thing sending the data ) then starts building a table that associates mac's with IP.. ( its called the arp table, and if you want you can see it from the command line ( arp -a for windows/mac/linux )...

Now consider what happens if two devices responded the arp.. the device would have two entrys in the mac table, and which one woudl be correct.. At best traffic would go to one device and not the other?


Some IP stacks will send you warnings.. others will not, and things just go odd. There are a couple of special cases where you do what seems crazy, but they are out of the scope of your question..


summary: using the same IP address twice is going to break things in 99.9% of situations.

"and same universe config?"

Unlike IP address's its completely acceptable for a device to use the same universes as another one.

Will they both do exactly the same thing,

Perhaps. If you are sending E1.31 from your controller as unicast packets ( 1 to 1 ) then as long as your controller is sending two copies of the data ( 1packet to device "A" and 1 packet to device "B" ) then it will. This can be set up normally in most controller software.


If you only send 1 packet to one IP address in unicast, something will miss out.

or will all the data go to the first controller it finds and ignore the other, or something else?

The data doe'nt "find" or choose where it goes. thats the function of the controllers that are sending it and the switch fabric that connects everything together.

Unicast vs. Multicast make a difference?

Yes. Unicast means 1 to 1 data.. ie, one source and one destination. Multicast means 1 source and one or more destinations. ( note multicast is not broadcast which means 1 to everything ). If you send data out as multicast ( which is really the way e1.31 was intended to be used by the folks to invented it ) it means that you can send one packet from your controller, teh switch sees that multicast packet and forwards it on to devices that want to receive it. ( it effectively will copy it to any port that needs it ).

Basically I'm contemplating setting up two identical props (megatree for example) and rather than using up twice as many IPs, universes, and lines in my sequencer, I'm hoping I can just program one and the other will be a clone.

My recommendation to you, is that you could identically configure your devices ( nearly ) by using DHCP to automatically address your devices. It just happens in the back ground.. Use multicast so you can just send the packets out and not worry about it as well!

 

[i13]

Using multicast, different IP addresses and the same universe setting on the controllers would do the trick. scamper's idea should work too but I haven't tried it; you can connect two wires to the data output of your pixel controller and get two strings of pixels doing the same thing.

You would be better off with a switch with IGMP if you use large numbers of universes and multicast. This video helped me understand what it does http://auschristmaslighting.com/forums/index.php/topic,8483.0.html