EPIC Groov does not like a disconnected cat5 cable

A frustrating situation arose with an EPIC Groov unit I have been integrating into one of our existing control systems and I would be keen to hear if anyone else has been caught out with it. In summary, I found that the unit appeared to stop running the loaded strategy shortly after I disconnected my development laptop from it. Normally during development or troubleshooting I would cut all the other network gear out of the equation and have my laptop connected directly to the EPIC processor on ETH0. I’m only ever running PAC Control strategies on the controller and run development of the GUI through the usual PAC Display Configurator. My usage of the EPIC controller at this stage in essence is just a continuation of how I’ve always operated with our various PAC-R1 systems.
Our systems need to run autonomously some of the time without any input or output via PAC Display. So once a system is up and running and I have finished tinkering with the laptop connected I would typically disconnect the laptop and move on to other machines etc, say to load up our Display GUI. In over 10years of developments using PAC-R1 setups the systems have always worked flawlessly and just carried on as expected with the strategies remaining active and with all the necessary charts running.
What I have discovered with the EPIC however, is that the very act of unplugging my cat5 cable from my laptop (All Opto programs shut down in Windows10 at this stage) somehow causes the strategy to either get confused or stop altogether. Inspection of the controller attributes on the EPIC front panel shows that the strategy is “Running” though there is a discrepancy with the number of charts that it says are running. As an example, I have some remote controller devices which have toggle switches hard wired to GRV-IDC-24 inputs on the EPIC rack which start and stop a few charts. When the cat5 cable is removed these charts do not start and stop (ie. the number of charts running does not change, nor does it actually reflect the actual number of charts that I know should be running in the idle state). Yet, with the cat5 still attached to my laptop, all is well and the charts start and stop as expected.
It is at this point I wondered whether there is something in the EPIC that is simply looking for a valid LAN connection to maintain a running strategy. Seems weird to me, but nonetheless, I experimented with just plugging the LAN cable from ETH0 on the EPIC and straight into a spare port on one of our ethernet switches instead, laptop entirely out of the mix. All the other traffic on this switch is non-DHCP fixed addresses and all of that is on a totally different subnet to where I have the EPIC set up. Interestingly enough, once the cat5 cable is plugged in and the port lights are flashing the strategy behaves as normal and responds as it is programmed to do.
So my assumption is that the EPIC needs a connection (even if it is to nothing) and my workaround for this problem is actually just to install a small switch that does nothing in the cabinet to act as a “friend” for the lonely EPIC controller. This way, if for some reason the outgoing cat5 cable that would otherwise connect this system (which is housed in one shipping container) to the rest of the network (other shipping containers) is unplugged the system will still function as planned.
Anyway, I wonder if I have missed something vital here or if others have encountered something similar? As I said, this is not something that has ever presented with all our PAC-R1 systems and perhaps I’m yet to learn some of the subtleties during this first play with an EPIC.
Oh and second quick question: Anyone else finding the power-on boot up time frustratingly long? What could it possibly be doing for 3+mins? Perhaps one for another thread.

1 Like

Have you set the IO Unit to localhost? I have seen when the IP address of the IO Unit is set to the static IP address (and not localhost), and that physical network is not available, that the strategy can not communicate to its own IO Unit. The IO Unit in the strategy then goes to ‘disabled’.


Dave: Just to be clear, are you saying instead of putting in a fixed IP address ( in our case), to write ‘localhost’ in the yellow shaded area?

Not the Control Engine, but the IO Unit setup.

1 Like

Thanks for the info. It had never occurred to me to use the checkbox for localhost on a rack that actually has the controller mounted on top of it. I have always set the IO Rack to the same physical fixed address as the controller on top. It has always worked this way so I have never had reason to try anything else. I have not got access to our EPIC controller at the moment so I can’t test the fix for my initial problem mentioned above but I have just done as you have suggested and changed over one of my PAC-R1 units and it works a treat. I am now wondering if this small detail doesn’t have something to do with some (maybe unrelated) latency issues I have been seeing with one of our other systems, which suffered a while back from some weird packet collision stuff in one of our switches.
So, just to clarify, are you suggesting by having the IO unit set to an actual fixed IP (but same as the controller) rather than localhost, that the controller sends all communications to its IO points out (say on ETHERNET1 on a PAC-R1) to say a switch and then back to itself (on ETHERNET1) to reach the IO points? Or is it just the fact the IO unit has a non-localhost IP address that is causing it to check for a valid cable connection and thus assume it has lost contact with the IO unit when the cable it unplugged?
If it is the former, then this would equate to a whole lot of unnecessary traffic from the controller out to wherever and back again would it not?
Thanks again for the info. Any further insight into the above would be greatly appreciated.

I always use the loop back checkbox on all snap racks that have a controller on them. This prevents a lot of unnecessary traffic on the lan. It also allow the controller to talk to the IO “internally”. I believe Opto considers this a best practice. True it will work either way, but it should be more efficient if you use the local host loop back… I will have to try to recreate the issue you mention with an epic and see if it is related. On early release epics there were some network hardware issues, but those usually manifested themselves around the MAC address and license.

No traffic should end up on the LAN when using the interface address. Localhost does avoid hitting that ethernet network stack though.

I encountered the exact same problem as yours.