OPC Device Driver Won't Connect, Works With Alternate Gateway

I have CompactLogix (newer than 20) driver that works on one gateway configure identically to a separate gateway attempting to connect from the same host that will not work. It goes from “idle” to “connecting”.

Here is the log from my new gateway:

However this same PLC is connected successfully to a separate gateway using the exact same configuraiton settings…



The only difference is that the new gateway is a newer version of Ignition 7.9.8 vs 7.8.2. It is a NAT’d hostname, but the device handles the NAT translation fine on the one so why would it not work with the other.


Sounds like a firewall configuration problem. Can you ping the PLC from the new gateway?

Yes I can ping it, but besides ICMP and 8088 I can’t recall what other ports I have opened on the firewall though. Is there anything specific I should look at?

This is going to get confusing, so I left this out of the initial post, but if I create a duplicate driver with just a different name on the WORKING gateway I get the same issue. If you look at my post history I had questions about a duplicate device so I could configure a project that was using a different version of ladder. I could never get it to work (the duplicate device on the working gateway, working in that at least the original device stays connected on that gateway) because of the exact same issue. This leads me to believe there is a configuration issue or an AB issue but the config settings are identical.

looks like 44818 is probably the culprit, I will report back

yup TCP 44818 needs to be open, should have looked more closely at error message. That is the eth/ip and rslinx critical port for Rockwell. Thanks for spurring me to troubleshoot firewall!

Keep in mind that Logix processors, especially the CompactLogix familiy, allow only a limited number of connections from outside – including HMIs --, and even less if the processor is also initiating connections to I/O devices or other processors. Ignition’s Logix driver has an advanced setting on how many connections to use (two by default) to allow higher throughput. You can overload in a hurry if you haven’t considered this.

great advice, do you have any rockwell specific articles on CIP connections per controller by chance? I am wondering if it makes sense for us to go to contrologix since we use a lot of remote IO and we have multiple OPC servers connected accomplishing different tasks. I am not necessarily married to rockwell controllers, I have used a bit of everything, but part of my company standardizing around Ignition was standardizing around Rockwell hardware so unless we have to change for example we can’t connect enough remote IO or something we will probably connecting to logix processors.

found it, pasting link and chart so maybe it will come up in a related search and save some folks time:

pg 18

I’m a very big fan of Rockwell’s processors. Not surprising if you are aware of my Ethernet/IP I/O driver for Ignition.

from Rockwell KN 474754 (updated 08/28/2018). There’s still node limitations, but the total number of connections has increased:

It doesn’t clarify exactly where the new limits apply, but it looks like Logix firmware v30.

I had a similar problem with a CompactLogix V20 controller over the weekend. The OPC device connection kept alternating between connecting and disconnected. I could successfully ping the controller from my desktop, and I had no problem getting online with the PLC using RSLogix via Linx.

When I tried pinging the controller from the IO server, the request would timeout. I tried several other computers around the plant, and all of them could ping the controller with no problem, so naturally, I suspected a firewall issue on the IO server.

However, it turned out to be the port configuration for the 1768-ENBT module. The gateway address was not set and the third octet of the subnet mask did not match the other operational controllers on the same network. I changed them using RSLogix, and immediately afterwards, I could ping the controller from the IO server. When I checked the OPC device connection status, I was happy to see that it had changed to connected in run mode.