I have a gateway that has 8 OPCUA Devices configured. 3 of them are not working properly. One is an A-B Logix Driver that is configured exactly like one on another gateway talking to the same PLC. This one that doesn't work is not the only A-B Logix Driver on the new gateway. Some work and some don't. The one that is troubling me is the one that works on the other gateway but doesn't work on this gateway. Both gateways are running v8.1.41. Any suggestions?
Hmm. Some difference in the gateways that we can't see?
Share more details.
What model of PLC? ControlLogix, CompactLogix? What firmware revision? Are they on the same network subnet? How many connections do you have configured (are you overloading the PLC?).
Make sure you can ping the PLC and have the correct slot number configured in the configuration.
As Phil said, we need a lot more details as there's no way for us to read your mind or your config.
I expect there is but I'm not sure where to look. I've checked obvious things.
That's why I'm concentrating on the one that works on one gateway but not the other. This shouldn't have anything to do with the PLC then. Also, I disabled the other gateway's driver in case the PLC was overloaded, but still no joy with the new gateway for that same PLC. When I re-enable it on the other gateway, it reconnects just fine.
I can ping the PLC. The configuration is exactly the same as it is in the other gateway.
This is the timeout message:
java.util.concurrent.CompletionException: io.netty.channel.ConnectTimeoutException: connection timed out after 2000 ms: /192.168.130.104:44818
at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.completeThrowable(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.postComplete(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(Unknown Source)
at com.digitalpetri.enip.EtherNetIpClient.lambda$bootstrap$8(EtherNetIpClient.java:391)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492)
at io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636)
at io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:629)
at io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:118)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe$1.run(AbstractNioChannel.java:262)
at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98)
at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:153)
at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: io.netty.channel.ConnectTimeoutException: connection timed out after 2000 ms: /192.168.130.104:44818
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe$1.run(AbstractNioChannel.java:261)
The packets are getting dropped. Ping is not a definitive test--it just checks the ICMP path, not the port actually needed (44818).
In the future, tell us these obvious things. We can't help you without them.
Ping is just used as a quick test to see if the network is routing packets properly. Although it's not always a good test if there's a possibility of an IP conflict and you're pinging the wrong device. How are the networks configured on the 2 gateways? Is there any VPN software that could be interfering with the communications where a network on the VPN is the same network as a local LAN?
If it's not on the same network subnet, make sure the firewall/router between the networks isn't blocking/filtering traffic on port 44818 from the gateway to the PLC.
There was much confusion regarding this with our IT department but it turns out it was just a firewall rule issue. Thanks.