Two Spaces, Two Ions, Two Unisons, and WiFi

I have space here in Skokie, IL with sort of a interesting setup.  As far as I understand ETC net 2/3 we should be able to do everything we want to and more, but I think the initial configuration was botched by the installer.  I inherited the network and consoles and have been trying to get it all to work together AND add some wifi loving on top of the buildings three domains or subnets. Almost everything is working beautifully, with the exception of two little hitches and I need some help to get through the last two bits.

I have two space denoted hereafter CE and NLT. (Mainstage and Small Rep theatre respectively)  here is my config.

CE Configuration -

Ion - 10.101.101.121 (Named NSCPAS-ion)

Subnet Mask 255.255.0.0

4 Dimmer Racks at 10.101.101.101 -> .104

NLT Config

Ion - 10.101.101.122 (named NLTION1)

RVI - 10.101.101.123

Subnet Mask 255.255.0.0

3 dimmer racks at 10.101.101.111 -> .103

There are four Ethernet switches address at various IP's and a couple locations for connections from the two booths to our dimmer and DMX distro room, I don't think these IP's are as important.  More specifically there is one in each theatre and two in the dimmer room.  (I would have exepcted only on in the dimmer room.  I think the person who did the original setup was a little overzealous and did not actually understand the needs of the building as a whole.

One idiosyncrasy here: the CE dimmer racks ethernet is plugged into one switch and the NLT dimmer racks are plugged into the 2nd switch in the dimmer room, so when we plug into the CE switch and any of the ports we can see everything but the 3 NLT dimmer racks and NLT unison control.

We have two Unison controls at:

10.101.10.101 and 10.101.10.102 these are a different headache altogether I will get to later. (One for each room)

There is also an Cisco enterprise level WiFi system(which is the project I am currently finishing and it works beautifully, if I do say so myself). For what I am doing here it hands out DHCP IP's from a DHCP scope of 10.101.101.131 -> .250 to ONLY WiFi clients.  (Basically there is a single interface of the Cisco WiFi controller configured at the IP 10.101.101.9)  The only place the building network intersects with the ETC Lighting network is at the WiFi controler. It is properly isolated so that only aRFR and iRFR and designer laptop WiFi traffic passes through.

For a while, I had everything up and running beautifully. Mine and 5 other people's aRFR or iRFR apps could see both consoles. The RVI could also see both consoles. All was happy... then. For some unknown reason the CE Ion dropped off the network. It was still spitting ACN and EDMX to the dimmers just fine, but the RFR apps and the RVI stopped being able to see it. This was fine, NLT was a little more important since they are headed into tech, so good that all could see thier Console. At a random point today the connectivity changed without any network changes happening. The CE Ion could be seen by the RVI, RFR apps, etc. and the NLT was nowhere to be found.

Just tracing everything I went to the dimmer room switch and noted the NLT port has no activity. It is connected but nothing is moving.(solid green light) On a hunch, I changed the physical port (to force a broadcast packet at the switch level)the NLT Ion was in and everything started humming along nicely again... for about 10 mins. The NLTIon dropped off the network again. Switch the physical port all is humming, then it dies again.  This REALLY doesn't make sense to me. 

I figure there is a setting I am missing somewhere that will solve this, I just am running out of ideas.

Everything involved with the ETCNet2/3 is configured with a subnet mask of 255.255.0.0 and there are NO duplicate IP's ANYwhere, I have double triple and quadruple checked that because I would feel like a bonehead if I duped IP's.

 

The second issue we are having is with the unison system and it has been a problem since it's install and noone has bothered to fix it.  It has taken me quite a while with show schedule to be able to suss it out and come up with accurate verbage to describe what is happening.

 

Two Unison controllers, one for each room.  Each is connected to it's respective switch.  When we connect the two switches together, we get lights coming on in opposite space that correspond to worklight or house light dimmers in the other space.

 

For example -

We see lights on in NLT on dimmer that correspond to two worklight dimmers we have in the CE space.  And they go off when we kill the worklights in CE.

 

The converse is also true.  Although it is a littel more dramatic because NLT's houselights are all in the range of dimmers we have in our onstage plot on the CE side.

 

It is pretty obvious to me what is happening that there is cross talk between to two unison controls when they are connected.  I just have no idea how to fix it.

 

Shouldn't everything in the dimmer room just be plugged into ONE switch?  So we can see all parts of the network from ANY ETCnet port in the building?  And then only be using ONE unison control configured with two rooms?

 

Ultimately, I think the correct answer would be to go down to a single unison control with two rooms on it.  What me and the TD DID notice when we were looking into the Unison boxes is the on the CE side we noticed the dimmers for NLT start at 513... which should be just fine.  but in the NLT box both sets of dimmers start at 1.  Could this be the problem?  I guess I don't know how the Unison controls talk to the dimmers.  Are they hardline DMX?  ACN?  EDMX?

 

None of this is particularly problematic except that we want to be able to see all the dimmer racks from any place on the network and we want to be able to control the NLT dimmers from the CE Ion when we do full building events that use both spaces.  We do not want the unison panel buttons to necessarily function on both sides, just to be able to take control of the opposite theatres dimmers from our consoles and also to get the RVI work so we have a choice of which console it talks to.

 

Any help would be GREATLY appreciated.

 

  • In looking at your config, your have 4 racks set to be 10.101.101.101-104, and the next space has 3 racks set to 10.101.101.111 - 103.

    Can I assume you mean 113 as the final octet for the second set of racks, not 103?

    Are these CEM+ racks? One thing to remember with CEM+ racks is the third octet specifies a group number. This has no bearing on DMX , EDMX or sACN addressing or who can speak to the racks form where. It isolates certain aspects of a multivenue form other venues for the purpose of configuration for one.  Groups are also isolated as they can be quite chatty online, depending on what synchronization and communications racks are trying to do with each other.  When we do larger CEM+ systems we try to seperate them by venues into rack groups.  For instance in your case,  10.101.101.101-104 and 10.101.102.101-103.  The way your system is set up apears that  you could be pressing buttons in the first venues racks, and accidentally change settings in the second venue racks. Since racks synchronize by group, and share some information, keeping them seperate can prevent problems from spreading across rack groups. I'm sur eit will work just fine in the same group/ IP range, but there is always the consideration of reducing potetnial  problems.  How are these racks venues addressed for control by Venue/Rack?

    Your system sounds eloquently done and the possibilities and flexibilities can be very nice to have.  A risk of having a level of complexity such as yours, is if you leave your position, for instance, a lottery win, and the people who stay behind or replace you (in case you were in a pool with your entire staff)  do not have your knowledge of the system for troubleshooting, it can complicate future trouble shooting. Just something to think about. This can be offset by thoroughly documenting your layout in the new configurations, in Network structure, physical wiring layouts, backed up configs, Circuit maps and such, and thoroughly training of staff, shortly before retiring to your private island.

     The Installer probably didn't have much say by the time he received the paperwork and arrived onsite. Typically 12-18 months after the process started. He was probably following the standards we teach our installers. Most venues do not have your level of  knowledge or comfort with networking systems, and we try to keep troubleshooting simplified by these standards. It helps in those instances where there is a problem shortly before a performance, when time is of the essence.

    Systems are specified by consultants to be laid out in certain ways, using these standards to create stable independant systems.  While it can be useful in a more complex layout as you are implementing,  in most systems we do not recommend  DHCP, or cross room control even though they can be made to work. 

    Another consideration is the business end of how a job gets completed.  Without going way off topic,  there are many reasons a job gets installed as documented, submitted and approved by multiple groups, and to make major layout changes during installation can cause political issues for that job, and long term issues for the people involved on future jobs.  

     

     

  • bosox242 said:

    Not sure if you've tried it, but I connect as a client wirelessly. I know it's not recommended, but it has been working for me.

    For the past 4-5 years I've only used the client wirelessly. Best part about it is that the client software isn't restricted to 2 screens. I've worked on 3 screens from 1 laptop, and 4 screens with two laptops, all connected wirelessly. (I don't like using the page button).

    Only down side is wireless client can't keep up with fast effects.

Related