S4 won't send E1.31 DMX to sACN Gateway

[dwhales]

Hi all,

This has been a 3 day battle so far and I still cannot solve it. So here goes...
- Windows 10 Education (64bit)
- 16GB memory
- LOR S5 (v5.5.14) Advanced
- LOR Controller on LOR USB 485 (working fine)
- ETC Net3 4 port Gateway connected via Cat5E to separate lighting router (as suggested in documentation) and it is connected to the PC's network port.
- Both gateway and PC are static IP addressed: 192.168.2.25 + 192.168.2.75 respectively

Using the same PC with the same gateway connected exactly as mentioned above, I can run the ETC EOS Nomad lighting software (which I have done thousands of times on various live performance shows and events) and the system works flawlessly.

But running LOR, it will not send DMX to the gateway and out to the lighting equipment.

Here are some "I have already tried" scenarios:
1) Tried direct Cat5E between PC and gateway (did not work)
2) Tried Cat5E through network switch then to gateway (did not work)
3) Tried different cables (but as I mentioned, system works fine in ETC software)
4) 2 years ago (I was away last xmas!), I used this same gateway and router/switches, but different PC and S4 advanced and it worked fine

I have attached various screenshots to show my current settings. If anyone has ANY idea what I might be doing wrong, please help! I'm about to jump off the roof (not really!)

Thanks so much for your time and assistance.

Darren

[jfuller8400]

A couple of things I would try first:  from a command line can you ping the ETC device (PING 192.168.2.25)?  If the ping fails, then you probably have some type of network/routing issue.  Try running a TRACERT 192.168.2.5 which should tell you where the network traffic is being directed.  You mentioned having a "separate network router".  Is this an actual router or just a switch (they are different devices).

Another thought:  In S4, you had to have the LOR Comm Listener running in order to send out E1.31 data.  Does S5 work in the same way (I'm not running S5 so I don't know).

 

 

[k6ccc]

Does your ETC device give you any status indication - such as packets received?

When you start sending, do you see network activity on the network switch or router that you are connected to?

Here's the big one - Windows Firewall.  As  recall, E1.31 will NOT get out through the Firewall.  Depending on how the computer is set up, it MAY automatically pop up and ask if you want to allow it on the first time you run a new program.  That could easily explain why one program can work and another does not.  As a test, disable the Windows Firewall and see if it work.  Then turn the Firewall back on and confirm that it no longer works.  If that is the case, add LOR to the Firewall.

 

[dwhales]

Hey Jim and JF, thanks for your assistance.

So here's where I'm at now...
1) as suggested, I ping'd 192.168.1.25 (see attached - I changed IP and router/switches back to the original system on the 1.x) - ping results perfectly normal
2) also tried TRACERT 192.168.1.25 and the results were as expected...perfect
3) tried disabling all Windows Firewalls etc...no luck...no difference
4) tested ETC Nomad software in all of these configurations as well and that software/system continues to work fine for all DMX lighting regardless of IP address and network
5) The Comm Listener from S4 seems to be built into the control panel in v5 now and when I start CP, it says its connected to the comm listener
6) I have added some screenshots of the ETC software showing its patch (15-17 RGB) to match the same patch I have in LOR

Any other odd thoughts on what LOR might or might not be doing?? This really seems so silly. Is there a way to see commands being sent when an LOR sequence is playing?

Thanks again, guys.

Darren

[Orville]

Not running S5 as yet, but are you running any malware or anti-virus software?  If yes, I had to go into these and set LOR to be exceptions, before I did that, some LOR stuff would work and others wouldn't.   Liked to drive me insane, then I had a thought and went into my virus protection programs and made an exception for the LOR software.   No problems ever since.

But that also means I can't run a scheduled scan on my LOR directories, I have to do a manual scan on those to make sure they are clean, which I do twice a week.

But that's the only other issue that I encountered other than the Firewall, as all these were blocking the LOR software from running properly or at all.

Good Luck.

 

 

[dwhales]

Thanks, Orville.

On this PC, I only have Windows Defender running. And making app exceptions for LORCommListener didn't improve the situation any.

However...

I was trying to prove more points and I went into xLights to see if I could get a single fixture to turn on in that software (since my ETC software works totally fine). Oddly enough, it didn't. So...I was looking at the settings in xLights and the only thing I had not yet tried related to the network was switching from UniCast (static IP address) to MultiCast. And F me...it worked!!

So I went back to LOR and did the same change...but strange, it seems the software sends out IP addresses that aren't even on the same network (see image attached - my gateway is still static addressed at 192.168.1.25). And yet, it worked! Damn, after 72 hours straight, I was ready to throw it all in the bin and switch to Judaism! :P

Thank you, everyone for your advice and assistance. I am just so flustered with this because I have never had to remove the IP address from my Gateway in LOR to get the system to work before. So why this year? I even went back to S4 (that I used 2 years ago) and it wouldn't work there either. Maybe it's just changes in Windows 10 that are screwing with me...I wouldn't doubt it...I am not a Windows fan at all. Wish LOR had a Mac version and I would be a super happy puppy!

Happy holidays everyone, and stay safe...PLEASE!

Darren

[k6ccc]

The 239.255.x.y address is what always shows (on lots of stuff) when you use Multicast.  Essentially it's s dummy placeholder.

So your ETC device is MultiCast only - that in my opinion puts it about 2 steps above CRAP.  Anyway, glad you came up with the solution.

 

[dwhales]

4 hours ago, k6ccc said:

The 239.255.x.y address is what always shows (on lots of stuff) when you use Multicast.  Essentially it's s dummy placeholder.

So your ETC device is MultiCast only - that in my opinion puts it about 2 steps above CRAP.  Anyway, glad you came up with the solution.

 

hahaha

Thanks, Jim. However, just to be a realist about this...check out etcconnect.com and take a look at the “CRAP” you mentioned. Considering this company is the world leader in lighting consoles, fixtures, motion control, etc etc etc...and every theatre on Broadway and thousands around the world uses their gear, it is clearly not even close to CRAP. Oh, and I never said my ETC Gateway could not do DHCP addressing. But managing any decent network is done with STATIC addressing so you always know where something is. Even LOR does that with their ID numbers.

I still appreciate your assistance, regardless of your opinion.

Thanks again,
Darren

[k6ccc]

Actually you missed my point.  From a networking standpoint, multicast is evil and should never be used unless there is a specific requirement for it.  ETC may be great hardware, but their networking leaves something to be desired.  Unfortunately that is not all that uncommon.  For example, I work in the two way radio field.  For public safety grade equipment, Motorola is king.  Their hardware is second to none.  However the software used to program those radios leaves a lot to be desired.  Motorola knows how to build a radio - not how to write software.

And multicast vs unicast has nothing to do with static vs DHCP addressing.  The two are completely unrelated.

 

[dwhales]

11 hours ago, k6ccc said:

Actually you missed my point.  From a networking standpoint, multicast is evil and should never be used unless there is a specific requirement for it.  ETC may be great hardware, but their networking leaves something to be desired.  Unfortunately that is not all that uncommon.  For example, I work in the two way radio field.  For public safety grade equipment, Motorola is king.  Their hardware is second to none.  However the software used to program those radios leaves a lot to be desired.  Motorola knows how to build a radio - not how to write software.

And multicast vs unicast has nothing to do with static vs DHCP addressing.  The two are completely unrelated.

 

Very odd. Maybe you could help explain why, in LOR, when you click on MULTICAST, you lose the ability to place an IP address into the software? I honestly must be missing something. Cause the moment I click MULTICAST, I lose the ability to say "hey, my gateway is 192.168.1.25". Basically, the software has no idea my gateway is that IP address cause its just blasting the signal to all devices at the same time hoping someone will listen. The whole point of Unicast is forcing the signal to once device and nothing else, hence placing a specific IP address into the software so it knows who to talk to.

As for ETC, a properly engineered lighting network is insanely reliable. I work for a company that has 3 theatres completely ETC digital (using sACN) and everything is static IP, although the system may be set up Multicast (I can't remember), it is an isolated network that doesn't talk to billions of computers worldwide, just a few hundred devices within the theatre itself. So Multicasting that way does no damage to the signal or information sent around.

Thanks for your input and comments.

Darren

[k6ccc]

11 hours ago, dwhales said:

Very odd. Maybe you could help explain why, in LOR, when you click on MULTICAST, you lose the ability to place an IP address into the software? I honestly must be missing something.

That is correct. Once you switch to MultiCast, it becomes a broadcast.  You are not sending packets to a specific location (or IP address).  Every device on that Broadcast Domain will receive those packets and have to determine what to do with them.  Broadcast packets will go through a switch, and normally a bridge, but are not routed.

11 hours ago, dwhales said:

Cause the moment I click MULTICAST, I lose the ability to say "hey, my gateway is 192.168.1.25".

Correct - except that the 192.168.1.25 in this example is not a gateway, but rather a destination for the IP packets.  After that it is no longer IP.  The ETC then knows what to do with the packets - remove the DMX data that has been encapsulated in IP packets and send it out one or more RS-485 serial ports.  So to clarify my statement, as far as IP communication is concerned, the ETC is a destination - not a gateway.  In the overall DMX communication, the ETC is a gateway.  Yes, I am splitting hairs a bit, but it is an important difference.

11 hours ago, dwhales said:

Basically, the software has no idea my gateway is that IP address cause its just blasting the signal to all devices at the same time hoping someone will listen. The whole point of Unicast is forcing the signal to once device and nothing else, hence placing a specific IP address into the software so it knows who to talk to.

Correct.  One of the issues with Multicast in this application is that every device must process those packets enough to determine if that device cares about it or not.  That adds to processor requirements of each device, and more important, there is usually a hard limit to how many universes a device can hear.  For example, one particular pixel controller I know of has a 96 universe limit.  It there are for example Universes 1 - 120 blasting on the wire, and that controller is only using 11 - 106, it could miss traffic intended for it because packets that it does not care about were filling it's buffers.  There may be a better description of that, but I at least got the concept.

Another disadvantage of multicast is transport capacity.  We all sometimes forget that there is a hard limit to how much data can be shoved from point A to point B via whatever is transporting that data.  In most cases, it's not a big deal, but it can be.  Let's say you are blasting 500 universes of E1.31 data as multicast.  That is about 125 mega bits per seconds.  If you are trying to run that through a gigabit link, it should work just fine, but what if you have a link at a slower speed?  Not gonna work over a 100 Mb/s link.  If you have that 500 universes of E1.31 going over a gigabit link to a switch, and then that switch properly switches it to the 12 devices that it is actually going to, those could all be shower links if needed (WiFi or a microwave link for example).  Or maybe a E1.31 device that is limited to 100 Mb/s.  I just looked, and every single E1.31 device I have is 10/100 Mb/s, however my show computer is sending data out a gigabit link to the first switch, where the data splits to the various devices.  BTW, that is a very simplistic description as my LAN is a bit more complex than that.

One other note is that Unicast is routable.  For example, the computer I am typing this on is on my 192.168.101.nnn LAN.  Because I have allowed it, I can send packets to my E1.31 devices (primarily for testing) which are on my 192.168.131.nnn LAN.  Has to go through both of my routers to get there, but it works just fine.  Change that to multicast and it will not get there.  Granted that this is not something that you would likely see in a theater.

 

[dwhales]

Thanks, Jim.

FYI...when I say ETC and gateway, it literally is called "ETC DMX/RDM Four-Port Gateway". It is not a typical network gateway you would find in an IT office. It is just the name they gave to their E1.31 to 5pin DMX conversion boxes. I believe the newer term they use now especially for their smaller 1 port units is called a Node. But as I said...these are just "product names".

D