A/B Rack Failed

[waterboy 7]

I have a 8-slot Rack for PLC5 that just lost it's ability to receive data from slots 4,5,6,7. I have input modules in those slots and when I examine the data table for those slots (i:004/5 for example) I can change the input condition and the bit value doesn't change. Also I can type in a value to the bit location and change it to whatever I want and the input will have no effect on it. Output bits work the same way, I can force them and they do nothing. If I take that same module and move it to slot 1, it works normally. I replaced the rack and it is all fine now but there is no evidence on this rack of damage of any type. Has anyone else had this happen? Can I fix it? Edited 1 Aug 2007 by waterboy

[Ken Roach 194]

My best guess is that if you had a borescope you'd find corrosion on the card-edge connectors where the PLC-5 connects to the backplane, or that you'll find delaminated traces on some of the I/O bus lines on the backplane PC board. There aren't any active components on the 1771 backplane, so it has to be something physical.

[waterboy 7]

I used to do board repair ( still do when the need arises) so I know what to look for, but there just isn't any obvious evidence . like you said it's gotta be in the connector itself. Sure would like to actually see it. I wonder if I have one of those extension cards around here.... Have you ever experienced this before? Am I the first to have a bad backplane? Edited 2 Aug 2007 by waterboy

[BobLfoot 302]

You are definitely not the first to have a bad backplane. Had a 1771 go bad on me just last month. Our corporate policy finds board repairs not cost effective so we swapped racks and tossed the old one. I've also see similiar problems with 1746/1747 SLC racks. Have not seen a bad 1756 - controllogix rack yet, but then again they're much younger racks.

[waterboy 7]

Thanks, you're right of course, it's not cost effective and I did swap the rack. I just enjoy the chase sometimes.

[bkpsu 0]

Same symptom, different cause on the 1756 rack. During an install, we downloaded code to the controllers using a 4-slot rack, then went to put it in the configured 10-slot rack, and all modules past slot 3 wouldn't communicate. Honest mistake...This was rev 13, btw. -B.K.

[JesperMP 2]

I have experienced exactly the same on two occasions and with relatively new racks (at the time), and I know others that have experienced something similar as well. Reseating the CPU or modules in the slots cured the problems for me. I think that the connectors between the CPU/modules and the backplane is the weak link here. And of course the scary thing is that the CPU merrily continues to operate as if nothing is wrong. So i am guessing that there is no error-checking with the datatransfer from the CPU to the modules. If the same happens with an SLC, it will generate a major error.

[gravitar 3]

It does seem that the processor/adapter hasn't a clue of what is sitting next to it in a 1771 rack. SLC racks are considerably smarter (but perhaps for the same reason, they seem to fail more often too)

[drusso 0]

I installed a 1756 rack that failed from start. The cpu would not talk to the enet card. Tha A/B rep. did not act suprised. He replaced it the same day, no questions asked. NEW stands for Never Ever Worked!!!!!! thanks, drusso

[rdrast 3]

I've had a 1756 Rack go bad. Took a while to figure out too, as it kept showing up as a corrupt processor. Before changing the rack we were swapping out CPU's every day or so.