Detected Inoperative Conditions on Rack, CPU, Copro and RIO Head
Original instructions
Communication Timeouts
On every scan, the transfer of data between primary and standby CPUs ensures that they are synchronized. Timers in this communication are the first level of error detection:
  1. The primary CPU waits for the standby acknowledgement. A timeout here is due to an inoperative:
    • primary Copro
    • standby CPU
  2. The standby CPU waits for the primary acknowledgement. A timeout here is due to an inoperative:
    • standby Copro
    • primary CPU
  3. The primary Copro waits for the standby acknowledgement. A timeout here is due to an inoperative standby PLC.
CPU Sync-Link Interruption
There are 3 possible cases:
NOTE: The primary CPU maintains continuous activity on link, which allows the standby CPU to detect a comminutions interruption as soon as possible.
Inoperative Rack
There are 2 possible cases:
Copro Inoperative
The high speed CPU sync-link connects the primary and standby Copros. The primary CPU communicates with the standby CPU every 10 ms with either a:
The primary Copro waits for an acknowledgement from the standby Copro.
Detecting Copro errors:
If ...
Then ...
primary Copro reports a detected error to the primary CPU
primary CPU controller:
  1. acknowledges the detected error
  2. attempts to transfer control to the other controller by sending a take control command to the standby CPU through the RIO link
primary Copro does not respond within 5 ms to the primary CPU
primary CPU controller:
  1. detects and acknowledges the error
  2. attempts to transfer control to the other controller by sending a take control command to the standby CPU through the RIO link
primary CPU Copro sends a take control command to the standby Copro
primary CPU Copro:
  1. relinquishes control and becomes the standby CPU
  2. does not expect any response
standby Copro reports a detected error to the standby CPU
standby CPU controller:
  1. reports the error by sending a No standby CPU message
  2. goes offline
Inoperative S908 CRP RIO Head
There are 2 cases for inoperative S908 CRPs:
Inoperative Ethernet CRP RIO Head
There are 2 cases for inoperative Ethernet CRPs:
RIO Link Operations
The RIO CRP Head in the primary controller sends a health message about its links to the standby RIO 140 CRP Head every 5 ms.
Inoperative S908 RIO Link
There are 3 cases of an inoperative S908 RIO link:
Inoperative Quantum Ethernet RIO Link
This condition is detected by the both primary and standby CRPs.
If the standby CRP detects an inoperative Quantum Ethernet RIO network (it cannot communicate with the primary CPU), the standby CPU requests the primary CPU to check RIO network via its Copro:.
If the user application does not have the needed Link Redundancy FB implemented, an inoperative RIO network is detected by both primary and standby Quantum Ethernet I/O CRPs. The standby PLC goes OFFLINE while the network repairs itself. When the network works again, this PLC goes back online as the standby PLC again.