Question ControlLogix battery and communications

Join Date
Jan 2017
Location
Gulf Of Mex
Posts
36
ControlLogix 5561 processor. In the rack is a CNBR /D connecting to a remote flex I/O and an EBNT /A

Initially the only problem was 1) EBNT /A was showing the T003 Fail and 2)the processor had battery light and no program.

Connected over DF1, Loaded the program just fine, started looking at the T003 error on the EBNT. not fixable. Got a new part on a helicopter along with some "new" batteries. They have never been used, but they are OLD. One is Jun 2005 the other is Dec 2008.

Powered down to changed the EBNT and replaced the battery at the same time. Powered back up, Battery light is still on, now CNBR card LCD read out is "TEST" backwards. Cannot communicate over DF1 with the PLC or anything.

Replaced battery with the other "new" one, same indications.

Put back in the original battery, Got communications Kind of. Cant download but I can see everything in Linx. CNBR card still says TEST backwards.

Left it overnight. Choppered back to platform this morning. CNBR readout is ERROR UNABLE TO COMMUNICATE WITH BACKPLANE. tried resetting with a power of power on, Readout back to backwards TEST, Got good communications. Configure ENBT, Upload program, IO not responding.

Swapped slot for the CNBR card, still Test Backward. Changed battery and no communications at all.

what does the battery have to do with comms? what is the issue with my CNBR card? why is TEST showing backwards?
 
If there's a common cause it could be the backplane chip in the chassis itself, or you could have had a power spike that damaged all the modules.

Communication failure with the backplane is the main cause of the T003 failure on the ENBT, and the CNB module has told you it can't communicate with the backplane either.

The controller might have "lost" its program because of a dead battery and a power loss. In many cases the program is cleared intentionally because it fails a checksum test, but in your case because the battery was dead, it's genuinely a case of a dead battery + power loss, probably incident to some other event.

Rockwell has a Knowledgebase document (31474, access level: Everyone) that suggests that the mirroring of the TEST diagnostic text means the backplane or one of the other modules is damaged.

With the remoteness and presumed criticality of the system, I would declare all the modules, the power supply, and the backplane to be damaged and replace them all. If I had to choose just one element to replace, it would be the chassis itself.
 
Ken, I agree that it seems like the chassis is a likely suspect for the cause of these issues, but there are just too many things niggling at my brain that make me think this should be recoverable.

1) The Processor and CNBT card WORKED just fine. I reloaded the processor when I first started troubleshooting. The PLC downloaded the program fine at first and the CNBT card was showing A00XX something and the PLC started acting on inputs right away and shunt tripped a generator breaker and all the inputs were good. The only issue at that time was the EBNT card on the T003.

2) The CNBT card didnt start showing test mode UNTIL I shut the rack down to replace the battery and the EBNT card. Then it came back up staying in test mode until I left it sit overnight and finally THEN showed unable to communicate with the backplane.

3) I still do not understand what affect the battery could be having on serial communications. And the effects are repeatable. 3 or 4 times I have swapped the battery and when I have the original battery in, I have good serial comms to the processor. Either of the other two batteries I have no connection via the DF1. I am starting to think the test mode is somehow related. It stayed in test mode for HOURS and then finally displayed no connection to BP.

Someone suggested respanning the CNET network. I am not overly familiar with CNET but I have seen this done before and kind of know how to do it. I am just not sure how to accomplish that if I cant communicate with the card?
 
Ken,

I got it. That knowledgebase article was the ticket. I searched endlessly but I think that term "mirrored" test was the ticket.

I pulled all the cards other than the CNBT and powered up the rack. that kicked it out of test mode. Then one by one reinstalled the other cards. and its stayed up and running.

I think the problem was that when I was troubleshooting the T003 ENBT card I moved it in the rack. Then I just left it there. When I did finally remove it, the CNBT was stuck in that test mode. Removing all the other cards and powering back on kicked it out of test and I am up and running.
 

Similar Topics

A curious thing: If a Indradrive servo drive has firmware 20.xx in it, it can communicate with the ControlLogix using a generic (implicit)...
Replies
3
Views
1,695
Is there any way to stop a search from finding a text string inside a sub-tag name. For example: if I'm searching for "run" ... I only want to...
Replies
10
Views
2,115
Hi everyone, Suppose I have a periodic task to trigger some communications, and in this task I have a pointer that iterates for each...
Replies
3
Views
1,307
Hi all, I'm working on a wastewater plant where I have a ControlLogix PLC as the master PLC, alongside three packaged systems that are being...
Replies
10
Views
3,852
Why is my PID .PV (Process Variable) getting continually overwritten with some strange value every time the rung my PID Instruction is on goes...
Replies
4
Views
2,130
Back
Top Bottom