ETC NET3 4 Port Gateway Issue

M

mellinger

Member
Hi Everyone,

Posted this to the ETC Forums as well, but thought there might be someone to answer here as well:



Recently, our router that was connected to our NET3 4 Port Gateway died and thus our lighting board (ETC ION) stopped working with our lights. So we got our IT personel to come in and change the router and put in the new static IP into the gateway.


However, now when we plug in the ethernet cable into the gateway, some of our LED moving lights (Vello XP600's) blink randomly or scroll through colors. I still have control of the movement function of those lights, but seem to lose color control and shutter control. Some of the lights in the system though work fine though (same Vello XP600's).

When the ethernet cable isn't plugged into the gateway, these same led lights work just fine when the light board is off and we turn them on through seperate faders that are downstairs, so we can use those lights during meetings without having to have someone run up to our control booth and turn on the lightboard to run them. (hope that makes sense).

I tried re-patching the lights to see if that would do anything, but that did nothing. Also RDM is set to "off" in the gateway, so that can't be it either I don't think. Before having to switch to a new router and static IP, everything worked fine.


Also, I noticed on our splitter racks, the status lights are blinking green on a majority of the dmx splitters instead of normally being solid green.


Does anyone have any suggestions on what to do. I'm not sure what went wrong. Any advice or tips would be welcome.



Sincerely,
 
Sounds odd indeed. What is the new switch the gateway is plugged into? Is it providing the PoE to power the gateway, or is on DC?
mellinger said:
When the ethernet cable isn't plugged into the gateway, these same led lights work just fine when the light board is off and we turn them on through seperate faders that are downstairs
Click to expand...
OK - how are these LEDs getting DMX if not from the gateway? Sounds like your gateway's DMX is fed through some snapshotting device with faders.
 
Hi,

Apologies for not knowing our systems backend too well :(. As for the gateway, it's not new. The only thing that was changed in the gateway was the IP address. The old router that was providing network access to the gateway died, so we had to set up a new router and thus had to input a new IP address into the gateway. However, the gateway itself didn't change.

As for the control faders downstairs that runs the led's when the lightboard is off, I have yet to learn how those are set up, but I believe the dmx signal must be getting split somewhere I'd assume.

Thanks for the questions to get a bit more clarity. Not sure much of what I wrote above though gives much more clarity though.
 
Is the switch also acting as DHCP? If so, maybe there is no "exclusion zone" in its address range, so it's trying to hand out an address that is already assigned statically, and you're getting collisions. Hard to guess from a distance, but I'd check that. As others have said, you shouldn't have needed to change the address of the gateway.
 
I'm a little confused. Why didn't I have to change the IP address of the gateway? The router that was connected to it broke and was no longer receiving a connection from our network. So the etc light board wasn't able to communicate with our dmx lights. Where I work had switched the IP addresses as well recently where the old system started with 10.xxx.xx (rough example), but with the new network system they are now beginning with 192.xxx.xxx.

Sorry I'm not an expert at all in networking and a lot of it confuses me :( As for the DHCP, I don't believe so, however, I'd have to check with our IT person. Anyway, hopefully in a week or two we will hopefully get an ETC tech out here to check out our system, just was thinking I might be able to fix it on my own.

Thanks for the responses you all have made so far.
 
If it was all working before, and all that was changed was the switch, then there should have been no need to change addresses - the switch shouldn't care, so long as it (or anything else, of course) wasn't generating dynamic address assignments that clashed.

192.168.x.x and 10.x.x.x are the two most commonly used address ranges for private networks. I'd have expected your lighting network to be a 10.x.x.x range.
 
Ah, thanks for the quick explanation. So our system was on 10.x.x.x. range before, but recently our school has switched everything out and is no longer assigning static ip addresses in that range. So when the router went down, they decided to switch the static ip address assigned to it as well. Is it a problem that the new IP address is in the 192 range and not the 10 range? Why do most lighting networks go with the 10.x.x. range? Thanks again for helping me learn some of this.
 
Can we clarify - it is a router, i.e. it has a connection to the internet, not just a network switch (no internet connection)?

If it is a router, and it's been assigned as a 192.168.x.x address, where previously it was a 10.x.x.x address then anything that was previously statically addressed will need to be readdressed and given the correct subnet mask and default gateway. The job of a router is, unsurprisingly, to route packets between networks. In order to do this, each device needs to know where to send its packets if they're not "local" (essentially, not in the same address and subnet range). When using DHCP, this assignment and setup all happens automatically when the device requests an address, but without some configuring you can't be absolutely sure that the same addresses will always be assigned to the same devices, which is why static addressing is often used, but if things change then it's important that all the static addressing and any DHCP server's reserved ranges are correctly updated.

Is it possible that somewhere along the line the network has been partially reconfigured when the new equipment went in?
 
I'll have to verify some of this with our schools IT technician tomorrow.

After you mentioned it, I believe both setups were through network switches. Main difference was switching from the 10.x.x. range to the 192.x.x range. When we switched to the new range, our IT person also changed the subnet mask and default gateway to correspond with the new static IP.

So the more i'm thinking about it, the more I don't think it's an issue necessarily with our network and more likely has something to with the settings in our lights or DMX. Anyway, hopefully when the ETC Tech's come out, they might be able to spot the issue.

Thanks again for helping me understand networking a bit more. Would probably do me good to study up on it more since it seems to be more and more vital to know these days.
 
Yes, best to get someone on the ground to take a look at it.

BTW, the reason large networks tend to use 10.x.x.x addresses over 192.168.x.x is usually simply because it's a bigger range of unique addresses - eight and a third million, approximately, instead of about thirty two thousand, seven hundred and sixty odd, and more potential for logical "partitioning" the addresses into groups of related devices, which can all, still, communicate with one another.
 
Last edited:
is this network hitting anything other than the lighting system? is it tied into anything such as the schools computer systems or something? Most School IT don't understand the specifics when it comes to lighting networks and I question an IT professional that would change a bunch of devices static IPs out from what they are existing in currently to something that is new when the original fix was to swap the switch.
I'm going to venture a guess that the ETC tech will likely have them switch it back to a 10.x.x.x scheme for the lighting system as the lighting system should be physically isolated from any other network in the school.
 
Hi,

I found out some new information and hoping maybe we can figure this out now. We were going to have an ETC tech come in, but I don't believe the issue we have is with our lightboard anymore and think it's purely the network.

So some more context. I work in a school where we have a main theater with an ETC Gio Board running to 2 NET3 Gateway devices to the DMX lights in the main theater. We also have a blackbox theater with an ETC Ion running to 1 NET3 Gateway device to the DMX lights in the blackbox.

So recently when we had to change the IP information in the black box NET3 gateway is when we started having issues with the network and the lights in the blackbox blinking and not really responding well to the lightboard.

It turns out, that if I have the lightboard shut down in the main theater, the black box lights and lightboard work perfectly fine. So I believe there is a network conflict between the two boards.

So I'm hoping someone with networking knowledge or the ETC Boards could help out a bit.

One thing I noticed, is that board lightboards have the same IP gateway address. Is that okay, or should their gateway addresses be different.
Second thing I noticed is the the 2 NET3 devices in the main theater have a different IP gateway address from the NET3 device in the blackbox. The NET3 device that is in the blackbox has the same IP gateway address as the lightboards.

I believe there must be some issue from what I wrote up above, but not sure which part is the issue.

Hope this helps.
 
This is a network problem, but could also be solved with different configurations of the gateways and consoles--at least until you can convince your IT people to unbreak what they broke. When a gatway sees two different sACN sources on the same universe it merges the two with HTP (Highest Takes Precedence) logic. With conventional fixtures that's a lot more intuitive: if one console is telling a dimmer to be at 25%, then the other one has control from 25% to full, but can never make it go below 25%. Highest value wins. With LEDs and moving lights, it's exactly the same logic, but isn't as visually obvious. You see limited pan/tilt range, weird color mixes, and other things along those lines.

The (at least temporary) fix is to repatch/reconfigure the console and gateways in one space to use different sACN universes from the other space to eliminate that conflict. Your ETC tech can absolutely help with that.

The right fix is to separate each space onto its own lighting network that is isolated from each other and not connected to the rest of the building network & internet. This can either be done physically with separate switches, or logically with separate VLANs.
 
(deleted)
 
Last edited:
mellinger said:
Ah, thanks for the quick explanation. So our system was on 10.x.x.x. range before, but recently our school has switched everything out and is no longer assigning static ip addresses in that range. So when the router went down, they decided to switch the static ip address assigned to it as well. Is it a problem that the new IP address is in the 192 range and not the 10 range? Why do most lighting networks go with the 10.x.x. range? Thanks again for helping me learn some of this.
Click to expand...
Yes, that's perhaps the start of the fun. Might have a class B address with a class C netmask. Might have super-netting (partway between B and C) enabled in 1 device, but not the others. Is your network isolated from the bigger "rest of the school" network? If so, tell them to come back and configure your switch exactly as the old one was. Brand names and model names help us here. Many switches DO offer DHCP server functionality (as noted above) and if that's not configured to miss collisions with statics, all hell will break loose.
 
PS - where are you, anyway? Its likely one of us is not far from you. This is a very helpful community - your problem needs someone with a laptop and experience on the ground there with you.
 
Looks like the OP is in South Korea (doesn't say which part). Do we have any other members in that part of the world?
 
You must log in or register to reply here.

Similar threads

N
Pathway PWREP RDM Turn off RDM
Replies
9
Views
911
NJLX
N
S
Etcnet2 Node Dropping edmx
Replies
10
Views
679
ChrisB_SanDiego
ChrisB_SanDiego
L
Rat Stands Trio 4 with Powerline PSU
Replies
6
Views
664
Lite rite
L
M
DMX network for new led lights and movers
Replies
11
Views
2K
StradivariusBone
StradivariusBone
S
Colortran 24/48 Issues
Replies
3
Views
339
Ravenbar
Ravenbar

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back