Control/Dimming ETC Eos Client Disconnecting

[Scott Lumley]

I am trying to connect two computers running ETC Nomad, each with its own dongle/USB key. I am using a wired network, and initially it all connects great, but then the client says it lost connection with the master, which it quickly reconnects to, but then I have to click to synchronize the two. I was looking through the settings, and I can't find much that might help the two connect together, but came across engineered network vs standard network in the shell by where settings are configured for multiconsole. What is the difference?

I am guessing the issue I am having is probably just the network being too poor for Eos to like, I'm sure the wiring could be better. But was more curious on the difference between the two options for network type. But I'll also take any suggestions if there are settings I should be looking at to get this to work. Not the end of the world if I can't figure it out, won't be running it like this for shows anyway, but thought it could be helpful for rehearsals.

 

[Amiers]

all power options set to never turn off? It sounds like the computer is shutting off the usb and then eos does it’s thing to find it and reconnects.

 

[sk8rsdad]

You may want to look at whether you are using a "green" switch or the energy saving features on your PCs. Powering down a port or NIC will drop the connection.

 

[Scott Lumley]

I will have to check the power options on the pc. I totally forgot sometimes they turn off certain ports and stuff to help save energy.

 

[Scott Lumley]

I will add though that I can remotely connect to the primary system with a remote desktop software, and that doesn't seem to have any issues, even when I connect both ways at the same time.

 

[Amiers]

I will add though that I can remotely connect to the primary system with a remote desktop software, and that doesn't seem to have any issues, even when I connect both ways at the same time.

Then it sounds like USB options and not NIC options.

 

[brucek]

Check that all devices are running the exact same version of software.

 

[Scott Lumley]

Then it sounds like USB options and not NIC options.

I'll check the USB power settings, but why would that cause it to disconnect from the network?

Check that all devices are running the exact same version of software.

All devices are on the latest release, with the same library version.

When I get some more free time in the next couple weeks, I will play with some different settings and stuff and see if I can improve its reliability. I will definitely start with power settings though, and just make sure nothing is shutting down to conserve power, including USB. And like I said, it is likely just the network I am connecting through, they did weird things when they ran the cabling through the walls. My guess, if I run a new direct CAT6 cable between the two, with maybe a simple switch, it would probably work just fine.

 

[Amiers]

Nomad requires a dongle no? If dongle doesn’t stay powered up and the USB port “hibernates” eos can’t function. Eos sends out a reply wakes it up yada yada reconnected.

Direct might help and would keep it off the network from prying eyes that’s for sure but unless other things are acting up in the building that is on that network than it might be something else.

 

[Scott Lumley]

I forgot about the little dongle key thing. I know it is required to run in client mode, but not in mirror mode. I didn't notice any issues when running in mirror mode, but I also didn't stay in that mode as long since I couldn't really do much with that mode. So if the USB is disconnecting, then Nomad may be locking up since it thinks the key was removed, but then reestablishes the connection as soon as it searches for the USB key again. Maybe I will get a little time today to test that out. I did just check my USB power settings, and they were set to allow to turn off to save energy, so I changed that setting.

 

[Amiers]

Other thing you can do that’s quick and easy is a windows + r “cmd” ping /t on the ip of the other computer and see if it is dropping packets let it run in the background one day when you are messing about with them. This will tell you if the network is shotty or things are just going to sleep.

 

[Scott Lumley]

So I checked all the USB settings, and they are good. Still disconnecting though. I tried the ping test, and it didn't show any packets lost during the time either. Average round trip time was 0ms with the maximum at 12ms. When it lost connection though, it was nowhere near 12ms though. I suppose if I let the test run for a long time, it might show packet loss that didn't show up this time, but still thinking it must be something else.

Oh well, at least this isn't an urgent problem. Maybe one day I'll get it to work. I'll just keep playing around with some settings and see if I can figure it out. Thanks for all the suggestions though!

 

[Amiers]

Well I would say with all this good information you have gathered you can take this to the pros at ETC service desk and get past the initial troubleshooting that we just did. They are open 24/7 365. If they don’t call you back in 15 mins or less you get a free steak dinner .

 

[Scott Lumley]

Yeah, I know their support is great! I also came across what the difference is between engineered network vs standard... it looks like with a standard network, after five seconds of no response from the master, the backup will assume the master disconnected. With engineered, it is 1.6 seconds.

 

[John Palmer]

Since, you have said that they did some squirrely things when they ran the cable, do you know how long the cable run is on that segment? Do you have access to a tester that test for length and noise on the network line?
Also, what type of switches are you using?
Are you using the network to carry data to gateways and racks, or is the DMX data going out on DMX lines?
Have you tried a clean install of the EOS software? Maybe there is a weird glitch in the gitty-up.
Good luck,
John

 

[Scott Lumley]

Since, you have said that they did some squirrely things when they ran the cable, do you know how long the cable run is on that segment? Do you have access to a tester that test for length and noise on the network line?
Also, what type of switches are you using?
Are you using the network to carry data to gateways and racks, or is the DMX data going out on DMX lines?
Have you tried a clean install of the EOS software? Maybe there is a weird glitch in the gitty-up.
Good luck,
John

I'm not sure what the cable length is, but I know they initially made some of the cable runs too long, so they were forced to add a switch on our main floor and run some cables there instead of directly to our data and coms room on another floor. The lengths should be okay now though, but I don't have a tester.

The switches in play are Extreme Networks X440-G2-48p-10GE4.

The network is not being used to carry data to the dimmer racks, that is all hardwired DMX and then for some of our newer lighting, sACN on a separate closed network directly to the fixtures.

I haven't tried a clean install yet, nor have I tried using a different computer to connect with, but that would be something to try when we get the time. I've also been wondering if something weird is happening with the primary system, since it is connected to two networks, one for sACN and the other for the normal network to connect to other devices, like OSC apps and this somewhat working client or mirror mode. It's also possible the switches are doing something that causes the disconnects. The lighting system is on its own VLAN, but still shares the same hardware/switch as other devices on other VLANs. So there could just be a problem there.

I'm not too worried about it right now though, just thought it would be a nice feature to start taking advantage of. For now, I just use a remote desktop solution that gets by just fine. Maybe later this summer though, when we slow back down a little, I can try reinstalling the EOS software and play around with just creating a separate network not using the current switches.

 

[John Palmer]

You've got a lot going on with this. The VLAN could be the problem, but I use a VLAN on my network without issue. As a caveat, my network is isolated from the infrastructure network. It is just the entertainment tech services.
I have used both NIC's on my console to connect to different networks. As long as the settings in the shell are okay, it shouldn't be a problem. It doesn't sound like the console or your closed network are the problem, because you aren't seeing issues with the lights on that network.
Our network admin suggests turning on "loop protection" on the switches. Then you can run a report on the port to which the client is connected. That should tell you if the network dropped something. Typically, loop protection isn't on because it is a drain on the processor in the switch(s).
Because you are talking about building infrastructure, I am concerned that something like VoIP or some other process is causing packets to be dropped because of QoS (Quality of Service).
Also, it could be a spanning tree issue. The report will help isolate where the problem is.
Good luck,
John

 

[Scott Lumley]

I was also thinking it might be a QoS thing going on. Unfortunately, if it is anything to do with the switch itself, which seems to be the case, I won't be able to do anything about it since that will be all my IT department. I figured I would just see if there was anything I could change on my end though, but I think I covered it all based on the suggestions everyone gave me here. I ended up just using a remote desktop solution that worked mostly well.

 

[ScottT]

Before involving your IT department, try changing from Fast File Transfer to Normal File Transfer. Shell>Network>Interface Protocols, on the same line as MultiConsole.

Fast File Transfer vs Normal File Transfer in Eos Network Multiconsole settings

support.etcconnect.com

 

[Scott Lumley]

Before involving your IT department, try changing from Fast File Transfer to Normal File Transfer. Shell>Network>Interface Protocols, on the same line as MultiConsole.

http://[URL]https://support.etcconn...Transfer_in_Eos_Network_Multiconsole_settings

[/URL]

I did try switching between the two, but it didn't seem to make any difference. I though maybe going to normal file transfer would help, but I still ended up getting disconnected periodically.