Vixen 3: Assign same universe to two controllers

[Cmschleich]

I have 3 floods, they are fixed in address 1,2,3 | 4,5,6 | 7,8,9. I do not have a DMX reprogrammer and don't plan to get one.

Because of house layout they can't be on the same controller. Meaning in Vixen I have to send universe 1 data to two controllers. Through much experimentation I got it to work for 2017 & 2018. This year I'm not able to get it to work. My South controller has flood 1, my north controller has flood 2 & 3. In F16V2 config for the north controller I set both the DMX serial ports to start at address 1, this used to work. It will work this year if I set both serial ports to start with address 4, but then floods 2&3 don't work right for my xLights based sequences. I think I was on Vixen v2 in 2017, v3.x in 2018, and v3.6u3 2019.

Here is a screen shot of what used to work on the Vixen setup. Any ideas?

Untitled picture.png

[MartinMueller2003]

Send the universe that needs to go to multiple controllers using multicast. Then on each controller pick the channels from the universe being sent as multicast and you are done. Remember to not use the same universe number (ID) for any of your unicast universes as they will conflict and cause odd/interesting patterns in your output.

[jeffu231]

Seems like the 2&3 floods are just picking the first 6 channels of data in the chain if setting the start channel to 4 works. Have you tried just patching the 2 & 3 floods to channels 1-6 on the north controller and setting the start channel at one on the serial port?

[Cmschleich]

Seems like the 2&3 floods are just picking the first 6 channels of data in the chain if setting the start channel to 4 works. Have you tried just patching the 2 & 3 floods to channels 1-6 on the north controller and setting the start channel at one on the serial port?

I have not tried that. I'm not sure I understand what is occurring in the addressing at the packet level. I know the floods are hard coded for the addresses above, and one of the errors I see is 789 (North most flood) playing when 456 (middle flood) should, meaning it's interpreting the Northern most flood as the middle flood, and the middle flood doesn't do anything.

For Jeff's idea I'm not sure how to get around Universe conflicts error messages in Vixen, in the past I eventually stumbled upon a gerry-rig to do so, but it's not working the same this time (I would temporarily set one of the "DMX" controllers to a universe outside of used assignments, then set it back to universe 1, somehow bypassing the universe conflict message).

I can try both these ideas. Thank you!

[jchuchla]

If you're sending to two different controllers, and using unicast, you should be using two different controllers in vixen, and different universe numbers on each. I'm not understanding why you'd want to give them both the same universe number. Just pick a different universe number and make each controller listen for the appropriate universe number. But this of course would require that your xLights sequences are set up the same way.

The fastest and easiest solution was Martin's. Just switch to multicast for that universe.

[Cmschleich]

If you're sending to two different controllers, and using unicast, you should be using two different controllers in vixen, and different universe numbers on each. I'm not understanding why you'd want to give them both the same universe number. Just pick a different universe number and make each controller listen for the appropriate universe number. But this of course would require that your xLights sequences are set up the same way.

The fastest and easiest solution was Martin's. Just switch to multicast for that universe.

I'm under the impression I have to put them on the same universe, and specifically Universe 1, because the address at the end device has been fixed. For example with FPP's display tester, they only respond to commands sent to absolute addresses 1-9, they don't respond to 511-520 or anything higher. Do these DMX floods typically work differently and I missed something?

[jchuchla]

It sounds like someone set you down a vastly oversimplified path. And while what they helped you set up worked for that specific scenario, it bypassed learning a lot of the important concepts you really need to know to work with this stuff.

There is no concept of a universe in DMX. universes are an sACN/e1.31 concept. DMX contains up to 512 channels, that's it. Notice that there's no notion of universes on the serial outputs tab of the F16 setup. Universes only come into play when you're sending data via sACN. Your controller takes the sACN data from the network and converts it to DMX. So in your controller, you configure it to receive a specific universe and send it out the DMX port.

Where you seem to be getting lost is that the scope of address space isn't the same throughout the system. Sure your DMX floods are fixed to specific DMX channels. But all that means is that they listen to the first 3 channels on the DMX wire, or the next 3 channels and so on. What data is being fed to that DMX line, and therefore those channels is determined by the start channel values on the serial outputs tab of the f16.

The absolute channel numbers in the controller don't have any real correlation to the software. That's just a big block of channels within the controller. When you set up the sACN inputs tab, you're assigning universes to ranges of controller channels. For each universe, you're telling it which universe number to listen for, how many channels are in that universe and where to map those channels to the controller's channel block. Then on the outputs tab you're telling it which channels from that controller block it will map to that output.

You could easily map universe 1 to channel 48001 on the F16. Then you can take the data starting at controller channel 48001 and send that out the serial DMX output. It will take 512 channels starting at 48001 and send them out via DMX. That means the data that's on universe 1 channel 4 is lined up with DMX channel 4 on that particular DMX wire.
If you instead set up universe 3500 and routed it to the same F16 channel 48001, you would be sending the data from universe 3500 to the same DMX output.

Vixen adds another few layers of connections. You connect elements to channels, and then assign channels to universes. xLight is a bit more fixed, and it uses its own set of absolute addressing, which doesn't necessarily correspond with the absolute addressing on the F16.

So to make things work, you need to be able to follow the channels thru the whole system.

Vixen enforces the unique universes per destination rule. xLights does not. It's not fair to expect your initial solution to work when it's not a best practice in the first place. Vixen enforces the rule because sending the same universe to different destinations can create undesirable results. Especially when using DIY hardware.

[Cmschleich]

It sounds like someone set you down a vastly oversimplified path. And while what they helped you set up worked for that specific scenario, it bypassed learning a lot of the important concepts you really need to know to work with this stuff.

There is no concept of a universe in DMX. universes are an sACN/e1.31 concept. DMX contains up to 512 channels, that's it. Notice that there's no notion of universes on the serial outputs tab of the F16 setup. Universes only come into play when you're sending data via sACN. Your controller takes the sACN data from the network and converts it to DMX. So in your controller, you configure it to receive a specific universe and send it out the DMX port.

Where you seem to be getting lost is that the scope of address space isn't the same throughout the system. Sure your DMX floods are fixed to specific DMX channels. But all that means is that they listen to the first 3 channels on the DMX wire, or the next 3 channels and so on. What data is being fed to that DMX line, and therefore those channels is determined by the start channel values on the serial outputs tab of the f16.

The absolute channel numbers in the controller don't have any real correlation to the software. That's just a big block of channels within the controller. When you set up the sACN inputs tab, you're assigning universes to ranges of controller channels. For each universe, you're telling it which universe number to listen for, how many channels are in that universe and where to map those channels to the controller's channel block. Then on the outputs tab you're telling it which channels from that controller block it will map to that output.

You could easily map universe 1 to channel 48001 on the F16. Then you can take the data starting at controller channel 48001 and send that out the serial DMX output. It will take 512 channels starting at 48001 and send them out via DMX. That means the data that's on universe 1 channel 4 is lined up with DMX channel 4 on that particular DMX wire.
If you instead set up universe 3500 and routed it to the same F16 channel 48001, you would be sending the data from universe 3500 to the same DMX output.

Vixen adds another few layers of connections. You connect elements to channels, and then assign channels to universes. xLight is a bit more fixed, and it uses its own set of absolute addressing, which doesn't necessarily correspond with the absolute addressing on the F16.

So to make things work, you need to be able to follow the channels thru the whole system.

Vixen enforces the unique universes per destination rule. xLights does not. It's not fair to expect your initial solution to work when it's not a best practice in the first place. Vixen enforces the rule because sending the same universe to different destinations can create undesirable results. Especially when using DIY hardware.

Thank you much for this reply, I was missing the concepts suggested. It makes me think there could be a much better way to do this than I am currently which has always felt hacky.