AB Ethernet ENBT1756 Issue

I have a PLC that I am using with two 1756 ENBT cards, flashed up to 4.007. This PLC receives CIP messages from about 95 other processors. Two ENBT cards were used to split up the traffic.

The connection light on the first card stays on solid all the time and is communicating fine. The second card's light will drop out for a fraction of a second every 20-30 seconds.

Messages from some (not ALL??) of the other 95 PLCs will fail if sent through the second card to my PLC, but will complete if sent through the first card.

Does this sound like a network issue, or is there something I may have overlooked when setting up the cards?

NOTE: My PLC and 2 ENBTs are sharing a rack with another area's safety PLCs (2), its 1756 ENBT (1) and DNet modules (2).

NOTE2: I have this EXACT same situation occuring in another area under the same circumstances (1 PLC receiving messages from about 100 other PLCS and SOME messages fail if sent through one of the cards but not the other).

Any help is MUCH appreciated!

The very first thing I'd do, is pull up the web page for the ENBT modules, and look at the connection and processor loading.

Specifically, look under:
(For ENBT) "Diagnostics | System Overview".

(For EN2T) "Diagnostics | Advanced | Misc | System Data"

Specifically, you want to look at Maximum connections, active connections, and Maximum Observed / In use Peak.

I bet you are hitting a CIP connection limit on the ENBT's. They only support a maximum of 64 connections, where the EN2T's can handle 259 (IIRC).

Thanks for the reply!

The max observed does not exceed 50, and the max limit is 64.

Any other ideas?

Max connections per processor is 250 no matter how many enbt cards you have.

In most situations you will consume at least 1 cip connection and 1 tcp connection per device when dealing with i/o

There are three LEDs on the 1756-ENBT: LINK, NET, OK.

Which one are you referring to as the "Connection light" ?

The LINK LED is generally on steady, flickering when the module transmits.

Since connections fail much more often to the second 1756-ENBT than the first, I would start looking at the basic media counters first, and the port statistics second.

What kind of Ethernet switch are you using ? Have you captured statistics or diagnostics for the switch port ?

Have you checked the 1756-ENBT for the Atmel64 issue ? It usually results in a crashed module, but it's possible for it to just cause broken CIP connections.

How are the messages being sent? Do your "Master" PLC's perform a "READ"? Or do the "Slaves" perform "WRITES" TO the Master?

In 99.75% of cases, it is much better to have one CPU issuing only "READ" commands. "READ" commands have much less overhead then "WRITE" commands, and you can have a centralized diagnostic system to see if slaves are offline.

Next thought, is you might want to increase the CPU's timeslice for communications. Under the CPU Properties "Advanced" tab, bump the Overhead timeslice to 30%, and perhaps tick off "Reserve for System Tasks".

Both posts above are on point as well... What kind of Ethernet switches are you using? What is the topology? How many 'Switch' nodes are there between the ENBT's and the target devices? Switches can be cascaded, but there is a limit.

And what lights are dropping out?

Do you see anything odd when you open the module internal webpage for the ones having trouble?