1771 Rack w/Control Logix

[Mike Carter 0]

I have a question about what should be the expected result if a 1771 rack is faulted or loses power in a system that uses multiple 1771 racks with a Control Logix processor. We upgraded two PLC5 projects with a total of 11 1771 I/O racks into 1 Control Logix program. All of the racks communicate back to the Processor utilizing a pair of 1756 DHRIO modules in the local Control Logix rack, and 1771 ASB modules in each of the 1771 racks. We had a opportunity for failure analysis the other night. A fuse blew in one of the control panels shutting down the power to 2 racks. Obviously, all the equipment controlled by those I/O modules stopped working but an interlock relay related to that equipment that is controlled from another rack in another panel stayed energized because the logic in the program never went false. Why? The input and output states in the processor memory stayed in their last state when the rack faulted. Bit 00 in the chassis input status word was set to 1 (indicating a rack fault), but all of the data values stayed in their last state. After we recovered we duplicated the failure during the off shifts to see why. We checked the last state dip switch on the 1771 rack back plane and it was set to the position to retain the last state. We changed that dip switch so that the last state would not be held. Then we duplicated the failure. Looking at the controller tags we found that all of the input and output bits still maintained their last state value. Is this what should happen? It should be noted that once power is returned to the rack all of the I/O states do turn off in logic but during the power failure all of the logical inputs and outputs are still on. Within the program it knows nothing of the failure. At this point we are not monitoring the status of the rack but it would be easy enough to add logic that examines the status of the rack and take action if it is faulted. I just wonder if what we are seeing is normal. If the last state bit is set to off in this situation should the I/O table go to 0's when the rack faults or loses power? If anyone has any experience with this I would greatly appreciate their comments. Fortunately this incident did not result in an unsafe condition but I can see how it could in another application.

[Mike Carter 0]

I believe I have found the answer to the question. The 1771-ASB manual answers it in the Question and Answers section of the manual. It is actually the first question posed. Q. What happens to my inputs and outputs when an adapter communication failure occurs? A. On a communication failure, inputs in this rack will appear in the processor input image table in the last state they were reported to be in before the failure. Outputs in this rack will either remain in their last state or be turned off, depending on the I/O chassis backplane switch setting for output last state. We must add logic to our program to monitor the status of the racks and take action to control outputs that might remain high when they are dependant on the inputs from the faulted rack. At least it is here in the forum for someone elses benefit in the future.

[Ken Moore 23]

Thanks for the follow up.

[Ken Roach 194]

You figured this operation mode out correctly, and I wanted to post to reaffirm your conclusion. The 1771-ASB adapter is in charge of the I/O conditions in the remote chassis itself in the event of a communication failure. That's why you inform the adapter by means of a DIP switch what it is to do with the Outputs in the chassis. I've had a lot of people express surprise or dismay that Inputs do not all go to zero when communication is lost with a device on a network. I try to walk through the whole issue. If input words and bits all went to zero when a network adapter connection was lost, that would be a bad thing. Control programs that do not account for communication status would consider that a normal go-to-zero event and would be acting on incorrect input data. It would also be impossible to know the input data states at the time of input failure (since the state-before-failure isn't saved) making troubleshooting more difficult. So, you are absolutely right that your control program should monitor and react to Rack Fault bits on RIO to assure that it can handle conditions like the power-down or disconnection of a remote I/O rack correctly.