EOS in large network with multiple stages

We are going to switch from Cobalt to EOS. In Cobalt we could setup diffrent net so we got a list on startup, there we choose stage 1 or stage 3 depending where we are. Is this possible in EOS?... and if it´s possible, is there any guide to setup this or a guide that explain how to use a EOS in a multistage/TV-studio-system?

The old system we have 7 stage in a large network. Every stage could choose it´s own stage or from our WYSISWYG join a stage. We had in the system a UNIFI WiFI NET, so if you walk between two stage and connect via aRFR console 1 or 2 whitout changing WIFI and one setupcomputer. We have a fileserver that could be reach from every consolles and WYSIWYG. Our main coreswitch stops all the sACN-traffic between the stages. I would prefer to copy this setup to my new EOS-consoles or rethinking all the network structure.

Parents
  • A few ways you can approach it.

    You can run concurrently using multiple users and multiple cue lists. Each stage with it's own cue lists and consoles all on the same show.  The benefit and drawback of being able to control other stages from any console if you want to (or don't know what you are doing).

    You can run each console with an sACN offset on the same network. Give each console a block of 50 or 125 universes.  As primary they won't step on each other, in client you will see each console on the network you want to connect to. aRFR will see it the same.

    For the TV and Movies I work on I work with the first system.  As we are sharing set builds, effects, colors and working together.  If I was not working with the same team or if other companies were also shooting these stages then I'd do version 2.

Reply
  • A few ways you can approach it.

    You can run concurrently using multiple users and multiple cue lists. Each stage with it's own cue lists and consoles all on the same show.  The benefit and drawback of being able to control other stages from any console if you want to (or don't know what you are doing).

    You can run each console with an sACN offset on the same network. Give each console a block of 50 or 125 universes.  As primary they won't step on each other, in client you will see each console on the network you want to connect to. aRFR will see it the same.

    For the TV and Movies I work on I work with the first system.  As we are sharing set builds, effects, colors and working together.  If I was not working with the same team or if other companies were also shooting these stages then I'd do version 2.

Children
  • None of theese answer is what i hope for, after I worked with Cobalt.

    We don´t need to share or control other stage, we just would have them in the same network because of our WIFI for remotes. We have one SSID that routes in the RFR-traffic to our lighting network, isolated from all other traffic on that network.

    Option two: I have chosen to stop all sACN through my Core switch, so my 1st universe on all stage is universe 1. So I still have all universe on every stage free and not locked up on other stages. Easier when you make your setup on your DMX-nodes on every stage. :)

    Is there any network port that show all the concoles in the ACN-protocol? Kill port "3030" in your coreswitch and you would't see and communicate with the consoles on other stage?

  • I am not sure this will do it, but if you use consoles, IonXE and upwards you have 2 network ports on them. If I'm not totally mistaken you can run one as main output on a isolated network for each stage (Maybe 10.101x.x.x, 10.102.x.x and filter on 255.255.0.0) and the 2nd you run only remotes on and then in one big network over all stages. When longing in to the remote you pick what console to connect to and then that console only output on it's own stage.

    So you have one sACN V-LAN network for each stage  and one "global" network on another V-Lan for remotes.  And then you can have a remote ON/OFF macro on each console so you can turn it off during shows so that no one else can control your show. 

    Maybe someone at ETC can confirm if this will work. I do not have access to my consoles right now.

  • It could work... but the problem is that I would have some more control in the network and see stuff that is loocked out with this solution. ;)

    It was great with Cobalt and there NET-setup and software CongFuKitty... I could see all the consoles in the network, but I can´t communicate from stage to stage if I select diffrent net in the setup/startup. I had my sACN-blocker in the Core-switch and no sACN pass through to another stage. In this case I had standard setup for my stage switch and could easily change them, but I have full control.

    If I isolate one networkport to WIFI and FileServer, put sACN on a separated networkport i miss to control all our DMX-nodes in the network. I use ELC 3-port and via there software I got DMX-sniffer from my office and could help collegues under reharsel whitout going down on stage. Realy nice feature when we have 8 stage in the buildning, all connected togheter, to help and figure out why something don´t work in the rig. Is´t the conosles or a fixtureproblem?

    If I could stop the networktraffic on a IP-port in my coreswitch that consoles comunicate with each other, I got full control over the network but stop all the comunication between consoles on diffrent stages.

    Yes, I´m probably little crazy but I like my Cobalt networksetup to much... :)

  • But if they all run on two V-lans and they on Lan1 are only isolated by IP mask as in my example you can still go in and connect to the individual stages. you just need to be on the right ip range. Probably things like Concert or ELCs software will see all devices on the network without the need to be in the right IP range. Otherwise you just need to know that on stage X the IP is 10.104.x.x and log on with that setting on the compiuter.

    I have no experience of doing that, so I can't say if it is a good or bad thing to have one big network with 7 parts isolated only by IP and Mask... But with only sACN it maybe works?

    Not perfect but may get you where you want to.

  • Before getting into this is how I do it so it's the right way blah blah blah.... let's take a step back before searching for the solution you're looking for and look at the question. If I understand it you're changing from your old system to a new system, but would like it to work like the old system? Though related Cobalt and EOS can work in fairly different ways when we start talking about sACN networking.

    Rather than asking why can't EOS do what Cobalt does... can we instead go with...

    Why are you changing to an EOS platform?

    What solutions are you looking to EOS for?

    What is your current network architecture?

    Now for the how I do it bit... I run 7 stages, split between various subnets all on one ETCNet. They can run independently, connected as client, multiconsole, backup, and remote. So... no your new system is not Cobalt, but it IS EOS and provides you even more options and network flexibility.

    In summary, I think you might be better off flexing the possibilities of what EOS networking can do, opposed to making it do what Cobalt does. Otherwise, I'd ask why you're changing platforms?

  • Shortly why we change... Our Cobalt is rather old and it´s time to renew our consoles... Why bought a new Cobalt nowdays and why not buy MA? ;)

    I start with VLC, Congo over to Cobalt and have large knowledge about how we could work with separated stages in same network. Now I try to understand and found how it works in new world of EOS so I could setup a system that works from my office and on stage, without stage 1 do things on stage 2. It´s hard to found information about this. Guide how it works on a single stage with server, backup and clients to a large TV-studio with diffrent setups.

    We have a coreswitch in the middle and every stage has there own network switches. If we disconnect our coreswitch on one stage, we lose remote and fileserver. Easy if something strange happens in the rig, just unplug one cable and complete isolate the stage from rest of theater, and run our performance.

    It had happens that collegues start up in wrong "net", and turn on lights on other stage. We had before that I split sACN-universe on multiple stages, mainstage sACN 1-24, stage 2... sACN 31-44 and so one. Then a guest performande came and connected to the network and did not know how the sACN in our building works and start to turn on lights on wrong sACN universe. This I solved in our core switch to block all sACN-traffic between our stages.

    On our main stage we got 11 networkswitches, but we only have a maximum of two switces between console and DMX-node. The othwer stages have one or two networkswitches.

  • Well... the short reply is that I expect you're having difficulty finding it because one of the great things about EOS and ETC at large is that system design and architecture are at the wield of the end-user. A blessing and a curse. Are you working with an integrator or system designer? That's no judgement on you or your skill. You're in the trench and it's your house, you know what you need. An integrator and designer knows 5 places that did that 10 ways.

    You could... segment your network at the layer 2/3 level like you are.

    You could... put gateways into your network that limit the reach of guest sACN sources.

    You could... set users with limited outputs.

    You could...

    We... in a large multi purpose facility including broadcast...  do a combo of users, gateways and patching. If it's not patched "EOS" won't control it.. for the most part excluding human error. Stage 1 is patched only for stage 1. Can it technically control anything else on the network yes... if it were patched and the active user has access and if the gateways on that stage allow the passing of control in that universe....

    In your case I would focus on separating your control. Let the network be the network. Follow networking best practices and don't try to use your switches to manage sACN Control. Traffic yes, control no.

    Use EOS networking with gateway configurations and appropriate sACN Control best practices to achieve your goals.

    I think you'll have a lot easier time and expand the possibilities of control and reliability within your system.

  • I think the mistake here is to not reset and start over. You made a infrastructure based on a console specific funktion and that will never translate over to any other console. I think you should just "forget" what you had and sit down and do a list of your needs and wishes. Do a sketch over the way it is cabled and reach out to ETC tec support directly over e-mail. They have done complex installations all over the world and know how it can be done.

    It is a little bit like making a network based on MAnet, HogNet or Titan Net hardware, it won't work with another console.

    I made the move from Cobalt to Eos to and what I learned is to not say "Cobalt do this like this, why do not EOS do that" and instead "What do I want to get out of my console or setup and how do Eos handle that?" So take a step back and drop Cobalt from your thoughts and just look at what you have and what you want to get out of that and when that is clear, involve ETC and they can help you out. 

Related