Allen Bradley CRC Errors

[Dean Novak 0]

We have multiple Allen Bradley PLC's running a detention center.  They were previously running on RSLogics and connected via OPC DA. We have a driver now connecting directly to the PLC and are experiencing timeouts and connection failures.  The PLC's are running a version 4.x.x firmware and are from about 2008.  Running a diagnostic we receive no major or minor errors.  But looking deeper into the webpage, we see thousands of CRC errors.  On some as many as 1000 per hour or more. The PLC has 1 core and we moved the time slice to 70 communication / 30 ladder from 20 communication / 80 ladder which seemed to help immensely. 

My questions are:

1.  Should we be concerned about these CRC errors and are they the root of our connection issues?  If so, how do we resolve them?

2.  Is it possible that RSLogics was keeping the connection solid and because we were connected to it, we did not see any connection issues and the errors were not passed through to us?

Any feedback on this situation would be very helpful. 

 

[BobLfoot 302]

You make no mention of model number is this an SLC500, PLC5 or ControlLogix.  

Given this equipment is 16 years I suspect that a communications module is causing your CRC Errors.

CHanging the time slice gives the PLC more time to communicate and overcome the bad CRC errors.

[Dean Novak 0]

Realizing this is only a 1 core device. We changed the time slice from 20% communications  / 80% ladder to 70% Communications / 30% Ladder.  That seemed to stabilize the

communications considerably.  The models are 1756 L61, 1756 L63 and 1756 L71.  The errors are FDS errors.  Hundreds of thousands of them. We still are seeing intermitted timeouts

and disconnections occasionally.  

[pturmel 160]

8 minutes ago, Dean Novak said:

We changed the time slice

It is usually best to not change the time slice, but instead make the continuous task a periodic task, with a period dictated by your physical application.  The vast majority of applications don't need the main task to spin as fast as possible.

[Dean Novak 0]

This is a detention center and we are controlling the PLC from our application with an HMI operator interface.  Periodic task??  Are you referring to running the ladder once every 200MS instead of it spinning every 15MS?  Our application does not control that but I am sure we could set up the PLC to perform that way.  

Thanks, let me look into that.  Any other advice?  Are these CRC  (FDS) errors concerning?  Our subcontractor seem to feel they are normal and fine.  I'm not convinced.  Previously we were connected via OPC DA.  RS Logics was in between and we did not see these issues, even though they existed.  I believe it handled these minor time outs and reconnects.  

[pturmel 160]

10 minutes ago, Dean Novak said:

every 200MS instead of it spinning every 15MS?

Or some less aggressive change, like 25ms.  How quickly does the logic need to run?

10 minutes ago, Dean Novak said:

CRC  (FDS) errors

Are these CRC errors on a network port, or a backplane port, or elsewhere?  It matters.  I would expect a well-maintained system to run nearly error free.  You may have degraded hardware, or, more likely, degraded connections (network ports, backplane card slots, et cetera).  You have old hardware.  If its environment hasn't been kept squeaky-clean all these years, some connector corrosion is likely.

[Dean Novak 0]

There were a few on the network port until we changed the time slice.  Now the remaining are on the backplane.  

[pturmel 160]

I recommend dismantling the chassis, gently cleaning all the backplane connectors, and re-assembling.  But be prepared to buy a new chassis.  And do something to keep that control panel's interior dry.  (Bone dry.)

[Ken Roach 194]

FCS and Checksum errors on a network module are virtually always related to noise induced on the network cabling, or damage to that cabling.    They are not due to timeslice or CPU utilization considerations.  

Increments of one or two a day is normal.  Thousands per hour is interference, especially if they're causing connection failures.

The fact that the error counts are reduced when you reduce the frequency of packet exchange is just because there are fewer total packets being exchanged.  

If you're getting checksum errors on the ControlBus 1756 backplane, that's could indicate noise on the ground plane or generalized electrical noise around the system, rather than in the Ethernet or ControlNet networks.

I had a little experience with ControlLogix in a detention center environment.  The vendor wanted me to prove that the ControlNet wouldn't cause the I/O devices to fail ON if someone put 277 volts onto the cable, and was not convinced by the user manuals or industry certifications.   So we did:  480v 3-phase, one leg connected to the ControlNet trunk conductor.   It smoked the 1756-CNB immediately, but the CPU and the local I/O were well protected by the backplane isolation and kept on running.