Controllogix processor losing communication through backplane

Need Help!!!

I have a controllogix processor that after 10 days or so the HMI lose communications to processor, I can no longer see the processor through RS Linx, I can see all the racks and all the I/O but I can't see the processor anymore.

If I cycle power to the main rack the processor comes back up.

But after 10 days or so it's gone again.

The HMI's are on a seperate controlnet network. The I/O is on a differnet schelduled network, the plant is running fine, but like I said the HMI are losing communications.

I even tried installing a Ethernet card in a remote rack and I still can't see the processor. ALso I have a panelview on a seperate controlnet network in a remote rack and it loses communications the same time as the HMI.

Any suggestions?

THanks

The available information about this failure sounds to me like a defective backplane bridge chip on the controller. Call Rockwell Tech Support and ask how to determine if your controller (or network modules) could have a defective Atmel ASIC.

But that's just a guess. RA Tech Support is the right avenue to pursue this.

I am going to try the utilty from rockwell for determining if I have a bad chip this morning, processor is only a month old.

The problem that you describe sounds similar to what I have had on a couple of Atmel equipped PLC's. The Plant where I work just started up and then we found out about the advisory regarding Atmel chips. All 22 of our redundant PLC's are affected and some have given some strange problems. I am currently scheduling shutdowns and making preps to replace all of the modules. If the module that's giving you problems sat on a shelf somewhere for a while it may very well be in the service advisory.


Steve

Ran the utility today 5 modules affected and processor, so much for brand new


Thanks for the help

Could somebody elaborate on the utility, where to find it? We have had the same problem for over a year and have just been getting runaround from rockwell. And its a reacurring problem.
Thanks

I had a problem with exactly the same symptoms you are describing. My problem began to occur when I upgraded a L1 V13 processor to an L61 V16. My system has an ethernet HMI and a ControlNet panelview. I would loose HMI comms on both ethernet and cnet but I/O over cnet would continue to operate. When browsing both networks in RSLinx, the processor would appear with the red X. I also noticed that processor utilization in the cnet module would go very high.

I tried working through this with Rockell tech and althought they were helpful they were ultimately unable to find the problem. In my case I suspected in incompatibility in the old PV firmware and the new L61 V16. I upgraded to an Ethernet PV plus and the problem has not returned.

Look at technote id 41204.

We are experiencing an intermittent issue (last 2 weeks only) where it appears that we drop/ lose our backplane I/O and comm modules temporarily and then they magically come back to life.

Have run the support tool from Tech Note ID: 41204 and all modules scanned came back as "not found" which tells me the modules are not affected by the anomaly described in 41204.

Have also written some tracking code to GSV the status of each module using the EntryStatus and FaultInfo attributes. EntryStatus typically runs at 16896 for normal conditions and will drop to 4096 in a problem state. It is random as far as what modules drop out and when. i.e. sometimes just a couple modules, other times all the modules.

For all the modules - FaultInfo value has never deviated from zero. I am still learning how to interpret the EntryStatus & FaultInfo info.

Also - no major or minor faults show up under controller properties.

We originally thought it could be a PLC power supply issue but swapped it out and the issue still remains. (and is still intermittent).

The recent onset and the exclusion by serial number of the controller and backplane modules makes the Atmel bridge chip issue unlikely to be the problem, though physical inspection of the chips is the only way to be certain.

The EntryStatus is an INT datatype but only bits 12-15 are significant.

16986 decimal = 425A hex, so the EntryStatus value is 4.
4096 decimal = 1000 hex, so the EntryStatus value is 1.

"4" means a running connection, while "1" means a faulted connection. So there's no very useful information there, except as a means of timestamping and duration measurement.

Are all of the affected I/O modules in the same backplane, or are they located across a ControlNet or EtherNet/IP link ? It's possible that the backplane itself is the root of the problem, or that noise is getting from the power supply to the backplane.

Ken thanks for this... We replaced the backplane in the remote rack (controlnet) and no issues for the last 48hrs.