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:
-
The primary CPU waits for the standby acknowledgement. A timeout here is due to an inoperative:
-
primary Copro
-
standby CPU
-
The standby CPU waits for the primary acknowledgement. A timeout here is due to an inoperative:
-
standby Copro
-
primary CPU
-
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:
-
Copro-Copro link interruption
This condition is detected by both Copros. The standby PLC detects the interruption and goes OFFLINE. The primary PLC detects that the standby PLC has disappeared, reports it to the log and continues to scan the I/O as a Standalone PLC
-
primary Copro inoperative
This condition is not detected, the primary CPU continues to scan the I/O, but as a Standalone PLC. The standby PLC goes OFFLINE.
-
standby Copro inoperative
This condition is detected by both Copros. The standby PLC goes OFFLINE. The primary PLC detects that the standby PLC has disappeared, reports it to the log and continues to scan the I/O as a Standalone PLC.
NOTE: The primary CPU maintains continuous activity on link, which allows the standby CPU to detect a comminutions interruption as soon as possible.
There are 2 possible cases:
-
Inoperative primary rack
The standby PLC detects that the primary PLC has disappeared and takes control of the system. It scans the I/O as a Standalone PLC.
-
Inoperative standby rack
The primary PLC detects that the standby PLC has disappeared, reports it to the log and continues to scan the I/O as a Standalone PLC.
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:
-
data message
-
health message
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:
-
acknowledges the detected error
-
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:
-
detects and acknowledges the error
-
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:
-
relinquishes control and becomes the standby CPU
-
does not expect any response
|
|
standby Copro reports a detected error to the standby CPU
|
standby CPU controller:
-
reports the error by sending a No standby CPU message
-
goes offline
|
Inoperative S908 CRP RIO Head
There are 2 cases for inoperative S908 CRPs:
-
inoperative primary CRP
This condition is detected by both the primary and standby PLCs. The standby PLC takes control of the system. The primary Copro goes offline.
-
Inoperative standby CRP
This condition is detected by the standby PLC, which reports the condition to the primary PLC and then goes offline.
Inoperative Ethernet CRP RIO Head
There are 2 cases for inoperative Ethernet CRPs:
-
Inoperative primary CRP
This condition is detected by both the primary and standby PLCs. The standby PLC takes control of the system and scans the I/O, but as a Standalone PLC. The primary goes OFFLINE.
-
Inoperative standby CRP
This condition is detected by the standby PLC and primary Copro, which reports the condition to the primary PLC.The standby PLC goes OFFLINE. The primary continues to scan the I/O, but as a Standalone PLC.
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:
-
interrupted link from primary CRP Head
This condition is detected by the standby CRP Head. The primary Copro goes OFFLINE. The standby PLC takes control of the system and scans the I/O as a Standalone PLC.
-
interrupted link from standby CRP Head
This condition is detected by the standby CRP Head and the standby PLC goes OFFLINE. The primary PLC continues to scan the I/O, but as a Standalone PLC.
-
interrupted RIO CRA Drop
This condition is not detected by the Quantum Hot standby system.
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 primary CPU is operational, it checks the RIO connection:
-
if the connection is OK, the primary CPU continues to control the system and the standby CPU goes to RUN OFFLINE
-
if the connection is inoperative, there is a Switchover. The standby CPU takes control of the system and the primary CPU goes to RUN OFFLINE
-
if the primary CPU is inoperative, the standby CPU takes control of the system
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.
