Ethernet between 2 CompactLogix Controllers

I am having an interesting problem with an Ethernet IP connection between two CompactLogix Controllers that I am hoping someone has some ideas about.

The two processors I have are a 1769-L32E and a 1769-L35E. They are connected via an Ethernet network and I am communicating between them via Produced and Consumed tags. The problem I am having is that the communications on the L32E is showing an error code 16#0203: "Communications Time Out" for the L35E processor. The really interesting thing about this problem is that sometimes I can get the communications to work for a couple of minutes (witnessed by monitoring handshake logic between the two processors) and then it will drop out. For note, there is no error displayed in the L35E processor.

FYI - I have the same communications working between this L32E processor and a 1756-L61 processor already. I have no problems with it.

So far I have:
1) rewritten both of the produced and consumed tags in the L32E processor (this actually seemed to get the communications working again - once),
2) rebooted the L32E processor (this seemed to work once, too),
3) removed and recreated the processor in the L32E program's I/O configuration,
4) adjusted the RPI time as high as 500ms for the produced tag in the L32E processor, and
5) verified the logic and tag configuration in both processors. So far, the handshake monitoring is all that is affected in either PLC by this fault.

I am not at liberty to randomly reboot or modify the tags and program in the L35E since it is a running machine at this time and I need to have a pretty good idea how to resolve the problem before doing so.

Anybody have any ideas?

Steve

Before going forward what kind of switch are you using to communicate them?

I am actually going through 3 switches - the first is an AB Stratix 2000 (1783-US05T), the second is the IT Department's switch (I don't know the brand/model) and the third is a Phoenix Contact 2891152 (a managed switch).

For what it's worth the other system with the L61 processor uses the same first two switches and another managed switch (I don't have the brand/model of it, either).

Switches

Bill might be on to something. As you may know, you must have one (or more depending on the architecture) managed switches...with "IGMP Snooping" enabled, if you are doing "i/o messaging". I/O (implicit) messaging goes out as multicasts, and if not filtered by an IGMP switch, will turn into broadcasts and clog your network.

Also, one often overlooked thing is to have all devices (switches and PLC E-Net ports) set to "autonegotiate". If one is set to auto, and the other is not, the network may defualt to half duplex for one and full for the other, and cause intermittent comm problems.

Hope this helps.

The first two things I would do is examine the I/O connection capacity of the both of the CompactLogix controllers. If they are using a lot of Ethernet I/O, you might be running up against a Connection limit. Usually the existing connections will remain and new ones will get refused, but that's not written in stone.

Use the built-in Web pages of the CompactLogix to look at how many connections you have running at once, and check the Ethernet port statistics for hints about any errors on the network.

Steve Etter said:

I am actually going through 3 switches - the first is an AB Stratix 2000 (1783-US05T), the second is the IT Department's switch (I don't know the brand/model) and the third is a Phoenix Contact 2891152 (a managed switch).

For what it's worth the other system with the L61 processor uses the same first two switches and another managed switch (I don't have the brand/model of it, either).

Click to expand...

Please take a look at the attached file, stratix 2000 is unmanaged and do not handle IGMP etc etc., the other two switches please find out if they are managed and handle IGMP, please follow Ken Roach´s recommendation.

Usually when there is a UDP flooding problem, it's the non-controller devices that are affected. I doubt the unmanaged switch is part of the problem. You can sniff one of the unused ports with Wireshark to get an idea of how much traffic is being multicast on that switch but I suspect it's not much.

A good way to sense connection failures is to use a GSV instruction to get the Module object's EntryStatus value from the Producing controller in the I/O tree. The high 4 bits of the INT type value are the important ones so I like to divide by 4096 to get a single-digit value. "4" means the connection is working, anything else is an indication that the connection is broken or re-establishing.

To diagnose a problem like this I would create a "mirror port" on the switch that is connected to the Consuming controller and attempt to capture the failure with Wireshark or another Ethernet traffic sniffer. You're looking to find out which device stopped cyclically producing traffic first.