FCS Errors between 1756-ENBT & 1794-AENT

Hi,

I have been chasing a nuisance connection problem between a 1756-ENBT & 1794-AENT for a while now. The symptom is that the yellow warning sign comes up in the IO tree and the outputs turn off, pausing the process for a while. I've done a lot of work on the basics to try and solve it. There are several other 1794-AENT's connected which give no problems.

I have recently noticed that this connection has a number of FCS Errors which build up over time (on diagnostics embedded web-site). Research tells me that it is essentailly a corrupted data packed where the CRC checksum does not line up with the rest of the packet. Indications are that electrical noise maybe compromising data transmission. Under most conditions the network stack will get over it and re-try the transmission. I'm wonder that maybe under the Multicast UDP that is being used, if noise is worse for a short time, no packets get through and the error at the IO connection error will occur.

I would like to have access to the FCS Error counter in the Logix program, so I can trend it and send it to Historian. Then I can see if the FCS error correlates to the IO errors we sometimes see (they don't happen often enough for me to sit and watch the screen).

Does anyone know if this value (FCS Errors) is accessible in any way (either from Logix5000 program or any other way).

Thanks

Good research !

The usual causes of FCS errors, along with alignment errors and retransmissions, are bad cabling, noise, poor grounding, and duplex mismatches.

Check the Autonegotiate settings on the switch and the 1794-AENT to be sure they are the same. This is probably the most common cause of connection faults that I see.

The 1794-AENT has a plastic frame so it's not usually as well grounded as a metal chassis system like 1756 or 1771 I/O. Some installations I've seen improve noise immunity by soldering a ground braid to the ground clip instead of relying on the DIN rail. If you can, ground the power supply V- that supplies the 1794-AENT. 1794-AENT Series B is generally more noise-immune than Series A hardware.

You can read the FCS errors counter, as well as all the other counters in the TCP/IP object (Class 0xF6), with a CIP Generic Message. This is well described in RA Knowledgebase Article 31324.

The timeout mechanism for EtherNet/IP connections does effectively include "retries" because it's a cyclic production mechanism. If the controller (or the adapter) does not see a packet produced by the opposite device for 4x the RPI (or 100 ms minimum) it declares a connection fault.

EtherNet/IP produced packets include a sequence number that increments by 1 every transmission, so if a receiving device sees an increment of more than 1 in the packets it receives, it increments a diagnostic counter for the connection for "lost packets" by 1. You'll see this in the diagnostic web pages for the 1756-ENBT.

oww, Ken that is helpful. Thanks!

I have already covered of the auto-neg settings since yes, the lack of a universal standard means this is not reliable. Fixing each end did make a significant improvement at the time.

I'll work on the other ideas and see how I go. Also noticed that part of the copper network is attached to a long mains cable, which could act as a source of interference and a nice antenna to boot.