Controllogix 5570/5560 Redundancy: User Manual
Controllogix 5570/5560 Redundancy: User Manual
Controllogix 5570/5560 Redundancy: User Manual
Activities including installation, adjustments, putting into service, use, assembly, disassembly, and maintenance are required to
be carried out by suitably trained personnel in accordance with applicable code of practice.
If this equipment is used in a manner not specified by the manufacturer, the protection provided by the equipment may be
impaired.
In no event will Rockwell Automation, Inc. be responsible or liable for indirect or consequential damages resulting from the use
or application of this equipment.
The examples and diagrams in this manual are included solely for illustrative purposes. Because of the many variables and
requirements associated with any particular installation, Rockwell Automation, Inc. cannot assume responsibility or liability for
actual use based on the examples and diagrams.
No patent liability is assumed by Rockwell Automation, Inc. with respect to use of information, circuits, equipment, or software
described in this manual.
Reproduction of the contents of this manual, in whole or in part, without written permission of Rockwell Automation, Inc., is
prohibited.
Throughout this manual, when necessary, we use notes to make you aware of safety considerations.
WARNING: Identifies information about practices or circumstances that can cause an explosion in a hazardous environment,
which may lead to personal injury or death, property damage, or economic loss.
ATTENTION: Identifies information about practices or circumstances that can lead to personal injury or death, property
damage, or economic loss. Attentions help you identify a hazard, avoid a hazard, and recognize the consequence.
IMPORTANT Identifies information that is critical for successful application and understanding of the product.
SHOCK HAZARD: Labels may be on or inside the equipment, for example, a drive or motor, to alert people that dangerous
voltage may be present.
BURN HAZARD: Labels may be on or inside the equipment, for example, a drive or motor, to alert people that surfaces may
reach dangerous temperatures.
ARC FLASH HAZARD: Labels may be on or inside the equipment, for example, a motor control center, to alert people to potential
Arc Flash. Arc Flash will cause severe injury or death. Wear proper Personal Protective Equipment (PPE). Follow ALL Regulatory
requirements for safe work practices and for Personal Protective Equipment (PPE).
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Summary of Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 1
About ControlLogix Features of the ControlLogix Redundancy System . . . . . . . . . . . . . . . 12
Redundancy Systems Redundancy System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
I/O Modules in Redundancy Systems . . . . . . . . . . . . . . . . . . . . . . . 14
Redundancy System Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
System Qualification and Synchronization. . . . . . . . . . . . . . . . . . . 15
Switchovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapter 2
Design a ControlLogix Redundant Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Redundancy System Redundant Chassis Configuration Requirements . . . . . . . . . . . . 22
Controllers in Redundant Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Redundancy Modules in Redundant Chassis. . . . . . . . . . . . . . . . . 24
Communication Modules in Redundant Chassis . . . . . . . . . . . . . 25
Power Supplies and Redundant Power Supplies in
Redundancy Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
EtherNet/IP Networks with Redundant Systems . . . . . . . . . . . . . . . . 28
Unicast Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Possible Communication Delays on EtherNet/IP and
ControlNet Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Bridge from an EtherNet/IP Network to a ControlNet
Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
ControlNet Networks with Redundant Systems . . . . . . . . . . . . . . . . . 30
ControlNet Network Requirements . . . . . . . . . . . . . . . . . . . . . . . . 30
Redundant ControlNet Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Other Communication Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
I/O Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1715 Redundant I/O Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Using HMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
HMI Connected Via an EtherNet/IP Network . . . . . . . . . . . . . . 38
HMI Connected Via a ControlNet Network . . . . . . . . . . . . . . . . 39
Optional Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Chapter 3
Install the Redundancy System Before You Begin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Redundancy System Quick Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Install the Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Install the First Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Install the Redundancy Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Environment and Enclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Prevent Electrostatic Discharge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Removal and Insertion Under Power (RIUP) . . . . . . . . . . . . . . . . 47
European Hazardous Location Approval . . . . . . . . . . . . . . . . . . . . 48
Safety-related Programmable Electronic Systems . . . . . . . . . . . . . 48
Optical Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Small Form-factor Pluggable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
North American Hazardous Location Approval. . . . . . . . . . . . . . 49
Laser Radiation Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Install the Second Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Connect the Redundancy Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Connect the Fiber-optic Communication Cable to
Redundant Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Connect the Fiber-optic Communication Cable to
Single Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Fiber-optic Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Use Dual Fiber Ports with the 1756-RM2 Redundancy
Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Update Redundant Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Upgrade the Firmware in the First Chassis. . . . . . . . . . . . . . . . . . . 58
Upgrade the Firmware in the Second Chassis . . . . . . . . . . . . . . . . 61
Designate the Primary and Secondary Chassis . . . . . . . . . . . . . . . . . . . 61
After Designation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Conversion from a Non-redundant to a Redundant System . . . 62
Qualification Status Via the RMCT . . . . . . . . . . . . . . . . . . . . . . . . 63
Reset the Redundancy Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Remove or Replace the Redundancy Module. . . . . . . . . . . . . . . . . 64
Chapter 4
Configure the EtherNet/IP Requested Packet Interval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Network CPU Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
IP Address Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Static Versus Dynamic IP Addresses. . . . . . . . . . . . . . . . . . . . . . . . . 68
Reset the IP Address for an EtherNet/IP Communication
Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
CIP Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Produce/Consume Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Chapter 5
Configure the ControlNet Produce/Consume Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Network Network Update Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
NUTs with Multiple ControlNet Networks . . . . . . . . . . . . . . . . . 81
Scheduled or Unscheduled Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Use a Scheduled Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Use an Unscheduled Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Add Remote ControlNet Modules While Online . . . . . . . . . . . . 84
Schedule a New Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Update an Existing Scheduled Network . . . . . . . . . . . . . . . . . . . . . . . . . 87
Check the Network Keeper States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Save the Project for Each Primary Controller . . . . . . . . . . . . . . . . 90
Automatic Keeper Crossloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Chapter 6
Configure the Redundancy About the Redundancy Module Configuration Tool (RMCT). . . . 91
Modules Determine If Further Configuration Is Required. . . . . . . . . . . . . . . . . 92
Use the RMCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Identify the RMCT Version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Update the RMCT Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Module Info Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Configuration Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Auto-synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Chassis ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Enable User Program Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Redundancy Module Date and Time . . . . . . . . . . . . . . . . . . . . . . . 100
Synchronization Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Commands in the Synchronization Tab . . . . . . . . . . . . . . . . . . . . 102
Recent Synchronization Attempts Log . . . . . . . . . . . . . . . . . . . . . 103
Synchronization Status Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
System Update Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
System Update Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
System Update Lock Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Locked Switchover Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Chapter 7
Program the Redundant Configure the Redundant Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Controller Enable Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Crossloads, Synchronization, and Switchovers . . . . . . . . . . . . . . . . . . 116
Changing Crossload and Synchronization Settings . . . . . . . . . . 116
Default Crossload and Synchronization Settings . . . . . . . . . . . . 117
Recommended Task Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Continuous Task After Switchover . . . . . . . . . . . . . . . . . . . . . . . . 117
Multiple Periodic Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Crossloads and Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Estimate the Crossload Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Redundancy Object Attributes for Crossload Times. . . . . . . . . 121
Equation for Estimating Crossload Times . . . . . . . . . . . . . . . . . . 122
Program to Minimize Scan Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Use a ControlLogix 5570 Controller with a 1756-RM2
Redundancy Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Use Multiple Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Minimize the Number of Programs . . . . . . . . . . . . . . . . . . . . . . . . 124
Manage Tags for Efficient Crossloads . . . . . . . . . . . . . . . . . . . . . . 124
Use Concise Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Program to Maintain Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Array (File)/Shift Instructions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Scan-dependent Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Optimize Task Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Periodic Task Configuration Optimization . . . . . . . . . . . . . . . . . 135
Continuous Task Configuration Optimization . . . . . . . . . . . . . 137
Change the System Overhead Time Slice . . . . . . . . . . . . . . . . . . . 138
Conduct a Test Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Synchronization After a Switchover . . . . . . . . . . . . . . . . . . . . . . . . 140
Program Logic to Run After a Switchover . . . . . . . . . . . . . . . . . . . . . . 141
Use Messages for Redundancy Commands . . . . . . . . . . . . . . . . . . . . . 142
Verify User Program Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Use an Unconnected Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Configure the MSG Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Set the Task Watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Minimum Value for the Watchdog Time . . . . . . . . . . . . . . . . . . . 148
Download the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Store a Redundancy Project to Nonvolatile Memory . . . . . . . . . . . . 149
Store a Project While the Controller is in Program or
Remote Program Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Store a Project While a System is Running . . . . . . . . . . . . . . . . . . 151
Load a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Online Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Support for Partial Import Online . . . . . . . . . . . . . . . . . . . . . . . . . 152
Plan for Test Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Assemble Edits with Caution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Reserve Memory for Tags and Logic. . . . . . . . . . . . . . . . . . . . . . . . 158
Chapter 8
Monitor and Maintain a Controller Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Redundancy System Controller Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Controller Logging in Redundancy Systems . . . . . . . . . . . . . . . . 160
Component Change Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Monitor System Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Verify Date and Time Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Verify System Qualification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Check Qualification Status Via Module Status Displays . . . . . 164
Check Qualification Status Via the RMCT . . . . . . . . . . . . . . . . . 166
Check the EtherNet/IP Module Status . . . . . . . . . . . . . . . . . . . . . . . . 166
EtherNet/IP Module CPU Usage. . . . . . . . . . . . . . . . . . . . . . . . . . 167
EtherNet/IP Module Connections Used . . . . . . . . . . . . . . . . . . . 167
Monitor the EtherNet/IP Network . . . . . . . . . . . . . . . . . . . . . . . . 167
Check the ControlNet Module Status . . . . . . . . . . . . . . . . . . . . . . . . . 168
ControlNet Module CPU Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 169
ControlNet Module Connections Used . . . . . . . . . . . . . . . . . . . . 169
Monitor the ControlNet Network. . . . . . . . . . . . . . . . . . . . . . . . . 169
Chapter 9
Troubleshoot a Redundant General Troubleshooting Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
System Check the Module Status Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Use Programming Software to View Errors . . . . . . . . . . . . . . . . . . . . . 173
Redundant Controller Major Fault Codes . . . . . . . . . . . . . . . . . . 175
Use the RMCT for Synchronization Attempts and Status . . . . . . . 176
Recent Synchronization Attempts . . . . . . . . . . . . . . . . . . . . . . . . . 176
Module-level Synchronization Status. . . . . . . . . . . . . . . . . . . . . . . 177
Use the RMCT Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Interpret Event Log Information . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Export All Event Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Export Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Contact Rockwell Automation Technical Support . . . . . . . . . . 186
Controller Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Event Log Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Event Classifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Access Extended Information about an Event . . . . . . . . . . . . . . . 190
Interpret Extended Information for an Event . . . . . . . . . . . . . . . 191
Export Event Log Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Clear a Fault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
System Event History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
System Event History Column Descriptions . . . . . . . . . . . . . . . . 197
Edit a User Comment for a System Event. . . . . . . . . . . . . . . . . . . 198
Save System Event History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Event Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Appendix A
Convert from a Non-redundant Update the Configuration in Programming Software. . . . . . . . . . . . 220
System Replace Local I/O Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Replace Aliases to Local I/O Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Remove Other Modules from the Controller Chassis. . . . . . . . . . . . 224
Add an Identical Chassis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Upgrade to Redundancy Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Update the Controller Revision and Download the Project . . . . . . 225
Appendix B
Redundancy Object Attributes Table of Redundancy Object Attributes. . . . . . . . . . . . . . . . . . . . . . . . 227
Appendix C
Redundancy System Checklists Chassis Configuration Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Remote I/O Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Redundancy Module Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
ControlLogix Controller Checklist . . . . . . . . . . . . . . . . . . . . . . . . 233
ControlNet Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
EtherNet/IP Module Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Project and Programming Checklist. . . . . . . . . . . . . . . . . . . . . . . . 236
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
Summary of Changes This table contains the changes that are made to this revision.
Topic Page
Added firmware revision 33.051 219, 224
This publication is designed for use by anyone responsible for planning and
implementing a ControlLogix® redundancy system:
• Application engineers
• Control engineers
• Instrumentation technicians
The contents of this publication are for anyone who already has an understanding
of Logix 5000™ control systems, programming techniques, and communication
networks.
Additional Resources These documents contain additional information concerning related products
from Rockwell Automation.
Table 1 - Additional Documentation
Resource Description
1715 Redundant I/O System Specifications Technical Data, publication 1715-TD001 Contains specifications on a Redundant I/O system.
1756 ControlLogix Controllers Technical Data, publication 1756-TD001 Contains specifications on ControlLogix controllers and redundancy modules.
ControlLogix 5580 Redundant Controller User Manual, publication 1756-UM015 Describes how to install, configure, program, operate, and troubleshoot
a ControlLogix® 5580 redundancy system..
High Availability Systems Reference Manual, publication HIGHAV-RM002 Provides information to help design and plan high availability systems.
ControlFLASH Firmware Upgrade Software User Manual, publication 1756-UM105 Describes how to use the ControlFLASH™ software to upgrade device firmware.
ControlFLASH Plus Quick Start Guide, publication CFP-QS001C-EN-E Describes how to use the ControlFLASH Plus™ software to upgrade device firmware.
ControlLogix Redundancy Update and Module Replacement Guidelines Reference Manual, Provides instructions for replacing modules or updating firmware in a powered-up
publication 1756-RM010 redundancy system.
ControlLogix System Selection Guide, publication 1756-SG001 Provides information on how to select components for a ControlLogix system.
ControlLogix System User Manual, publication 1756-UM001 Contains information on how to install, configure, program, and operate a
ControlLogix system.
Resource Description
ControlNet Network Configuration User Manual, publication CNET-UM001 Describes ControlNet® modules and how to use ControlNet modules with a Logix
5000 controller.
EtherNet/IP Parallel Redundancy Protocol Application Technique, publication ENET-AT006 Describes how to configure a Parallel Redundancy Protocol (PRP) network with the
1756-EN2TP EtherNet/IP™ communication module and a Stratix® 5400 or 5410
switch.
EtherNet/IP Device Level Ring Application Technique, publication ENET-AT007 Describes how to install, configure, and maintain linear and Device Level Ring (DLR)
networks that use Rockwell Automation® EtherNet/IP devices with embedded switch
technology.
EtherNet/IP Socket Interface Application Technique, publication ENET-AT002 Logix 5000Describes the socket interface that you can use to program MSG
instructions to communicate between a Logix 5000 controller via an EtherNet/IP
module and Ethernet devices that do not support the EtherNet/IP application
protocol.
EtherNet/IP Network Devices User Manual, publication ENET-UM006 Describes how to use EtherNet/IP communication modules with your Logix 5000
controller and communicate with various devices on the Ethernet network.
Integrated Architecture and CIP Sync Configuration Application Technique, Provides an explanation of CIP Sync™ technology and how you can synchronize clocks
publication IA-AT003 within the Rockwell Automation Integrated Architecture®.
Logix 5000 Controllers Common Procedures Programming Manual, Provides links to a collection of programming manuals that describe how to use
publication 1756-PM001 procedures that are common to all Logix 5000 controllers projects.
Logix 5000 Controllers General Instructions Reference Manual, publication 1756-RM003 This manual provides details about each available instruction for a Logix-based
controller.
Logix 5000 Controllers Information and Status Programming Manual, Describes how Logix 5000 controllers use connections with other devices.
publication 1756-PM015
Logix 5000 Controllers I/O and Tag Data Programming Manual, publication 1756-PM004 Provides information on how to access I/O and tag data in Logix 5000 controllers.
Logix 5000 Controllers Major, Minor, and I/O Faults Programming Manual, Describes how to monitor and handle major and minor controller faults.
publication 1756-PM014
Logix 5000 Controllers Nonvolatile Memory Card Programming Manual, Provides information on how to access and use a memory card in Logix 5000
publication 1756-PM017 controllers.
Logix 5000 Produced and Consumed Tags Programming Manual, Provides information to produce and consume system-shared tags and produce a
publication 1756-PM011 large array with a Logix 5000 controller.
Logix 5000 Controllers Quick Start, publication 1756-QS001 Provides information to program and maintain Logix 5000 controllers.
Logix 5000 Controllers Tasks, Programs, and Routines Programming Manual, Provides information to configure controller tasks and the programs and routines for
publication 1756-PM005 the proper execution of these tasks.
PlantPAx DCS Configuration and Implementation User Manual, publication Elaborates on the application rules that are required to configure a PlantPAx® system.
PROCES-UM100
Using ControlLogix in SIL 2 Applications Safety Reference Manual, Provides safety-related information specific to the use of ControlLogix modules in SIL
publication 1756-RM001 2 systems.
Redundant I/O System User Manual, publication 1715-UM001 Contains information on how to install, configure, program, operate, and
troubleshoot a Redundant I/O system.
Industrial Automation Wiring and Grounding Guidelines, publication 1770-4.1 Provides general guidelines for installing a Rockwell Automation industrial system.
Product Certifications website, rok.auto/certifications Provides declarations of conformity, certificates, and other certification details.
Topic Page
Features of the ControlLogix Redundancy System 12
Redundancy System Components 13
Redundancy System Operations 15
Restrictions 19
The redundant chassis pair includes two synchronized ControlLogix chassis with
identically specific components in each. For example, one redundancy module
and at least one ControlNet® or EtherNet/IP™ communication module are
required.
Controllers are typically used in redundancy systems, but are not required if your
application only requires communication redundancy. Your application operates
from a primary chassis, but can switch over to the secondary chassis and
components if necessary.
Features of the The software and hardware components that are required to configure and use a
ControlLogix Redundancy ControlLogix redundancy system provide these features:
• Redundancy module speeds of up to 1000 Mbps when using a 1756-RM2
System module with another 1756-RM2 module. Redundancy module speeds up
to 100 Mbps when using a 1756-RM/A with another 1756-RM/A
module, and a 1756-RM/B module with another 1756-RM/B module.
• The 1756-RM2 and 1756-RM2XT modules are interference-free
regarding safety functions and can be used in ControlLogix SIL 2
applications. See the Using ControlLogix in SIL 2 Applications Safety
Reference Manual, publication 1756-RM001.
• Redundant fiber ports for crossloading; no single point of failure of a fiber
cable.
• Plug-and-play-style commissioning and configuration that does not
require extensive programming.
• ControlNet and EtherNet/IP network options for the redundant
chassis pair.
• Easy-to-use, fiber-optic communication cable that connects redundant
chassis pairs. Use the same cable for the 1756-RM2 or 1756-RM/B
modules.
• Simple redundant controller configuration by using a checkbox in the
Controller Properties dialog box in the Studio 5000 Automation &
Engineering Design Environment® programming software.
• A redundancy system ready to accept commands and monitor the
redundant system states after basic installation, connection, and powerup.
• Switchovers occur as fast as 20 ms.
• Support for FactoryTalk® applications for Ethernet communication
modules including, but not limited to:
– FactoryTalk Alarms and Events
– FactoryTalk Batch
– FactoryTalk PhaseManager™
• Instruction Based Alarms (IBA) considerations:
– 5560 supports up to 250 IBA's with 250 burst
– 5570 supports up to 500 IBA's with 250 burst
– For more information see the Knowledgebase Article, ALMA/ALMD
instructions limits
• Support for CIP Sync™ technology over an EtherNet/IP network to
establish time coordination across the redundant system.
• Access to remote I/O modules over an EtherNet/IP network.
• Access to 1715 Redundant I/O systems over an EtherNet/IP network.
• Ethernet socket support.
• Support for PhaseManager.
• Supports PRP topologies. See the EtherNet/IP Parallel Redundancy
Protocol Application Technique, publication ENET-AT006.
• Supports DLR and topologies. See the EtherNet/IP Device Level Ring
Application Technique, publication ENET-AT007.
IMPORTANT For Ethernet modules, signed and unsigned firmware are available. Signed
modules provide the assurance that only validated firmware can be upgraded
into a module.
Redundancy System Communication between a redundant chassis pair that includes matching
Components components makes redundancy possible.
For more information about components you can use in a redundancy system, see
Chapter 2, Design a ControlLogix Redundancy System on page 21.
In a redundancy system, you can only use I/O modules in a remote chassis. You
cannot use I/O modules in the redundant chassis pair.
This table describes differences in network use for I/O in redundancy systems.
Remote I/O Module Placement Available with Redundancy System, Revision 19 and Later Available with Redundancy System, Revision 16 or Earlier
EtherNet/IP I/O network x -
ControlNet network x x
DeviceNet® network(1) x x
Data Highway Plus™(1) x x
Universal remote I/O(1)(2) x x
(1) In a redundancy system, you can access remote I/O modules on this network only via a ControlNet or EtherNet/IP network bridge.
(2) 1756-DHRIO module must be used with a channel configured for RIO.
For more information on how to use remote and 1715 redundant I/O over an
Ethernet network, see I/O Placement on page 36 and the Redundant I/O System
User Manual, publication 1715-UM001.
Redundancy System Once the redundancy modules in the redundant chassis pair are connected and
Operations powered, they determine which chassis is the primary chassis and which is the
secondary chassis.
The redundancy modules in both the primary and secondary chassis monitor
events that occur in each of the redundant chassis. If certain faults occur in the
primary chassis, the redundancy modules execute a switchover to the unfaulted,
secondary chassis.
When the redundant system is first started, the redundancy modules run checks
on the redundant chassis. These checks determine if the chassis contain the
appropriate modules and firmware to establish a redundant system. This stage of
checks is referred to as qualification.
Switchovers
• Loss of power
For more information about how tasks execute after a switchover, see Crossloads,
Synchronization, and Switchovers on page 116.
IMPORTANT During a switchover of the fiber channels of the 1756-RM2 module, scan
time encounters a delay of ~10 ms; however, the chassis always remains
synched.
Data server communication recovery time is the time during a switchover from
primary to secondary, when tag data from the controller is unavailable for reading
or writing. Data server communication recovery time applies to any software that
uses tag data, such as HMI displays, data loggers, alarms systems, or historians.
Data server communication recovery time reduction is important to increase the
availability of the system.
IMPORTANT • Prior to firmware revision 30.051, the communication delays apply only
when communication is exclusively over EtherNet/IP networks.
• With firmware revision 30.051 or later, the communication delays apply to
both EtherNet/IP and ControlNet networks.
IMPORTANT FactoryTalk Linx software is part of FactoryTalk Services, which has been
releasing a series of Service Releases (SRs) that are backward compatible
with any CPR 9 products. Existing and new users who are using FactoryTalk
View version 5.0 (CPR9) or later can use the data server communication
recovery time feature.
Some communication delays can occur during qualification. The existence and
duration of these delays depend on:
• Quantity and types of tags on scan in FactoryTalk Linx software
• Client screen and tag update rates (e.g. FactoryTalk Live Data/FactoryTalk
Historian)
• Number of data subscribers (i.e. FactoryTalk Alarms and Events,
FactoryTalk Batch)
• Size of the application in the redundant controller
• Controller loading, which includes the following:
• Number of tasks and scan rates (assumes no continuous task)
• Number of programs
• Memory usage
• Null task percentage available
• Network traffic
Restrictions There are restrictions that you must consider when using a redundancy system.
Most of these restrictions apply to all redundancy system revisions. Exceptions
are noted:
• See the release notes of the redundancy bundles for compatible products,
versions, and revisions
• The redundant controller program cannot contain these tasks:
– Event tasks
– Inhibited tasks
For recommendations and requirements that are related to programming
the redundant controller, see Program the Redundant Controller on
page 111.
• You cannot use the Match Project to Controller feature available in Studio
5000 Logix Designer® in a redundancy system.
• You cannot use motion in a redundant controller program.
• You cannot use SequenceManager.
• You cannot use consumed unicast connections in a redundancy system. If
you attempt to use consumed unicast connections, disqualification occurs
and qualification of an unsynchronized redundant chassis pair is not
allowed. You can use produced unicast connections that remote consumers
consume.
• Outputs controlled by specific instructions are not guaranteed to maintain
a bumpless transition during a switchover. Due to this, it is recommended
to avoid using the following instructions within a redundancy system:
– IOT
– HMIBC
• You can use a maximum of two controllers of the same family, and seven
ControlNet or EtherNet/IP communication modules in each chassis of a
redundant chassis pair.
• You can execute the tasks that were supported previously in a redundancy
system, revision 19.052 or greater.
01 12 13 24 40G 1 40G 2
01 12 13 24 40G 1 40G 2
Topic Page
Redundant Chassis 21
Controllers in Redundant Chassis 22
EtherNet/IP Networks with Redundant Systems 28
ControlNet Networks with Redundant Systems 30
Other Communication Networks 34
I/O Placement 36
Using HMI 38
Optional Software 41
This chapter explains how to use the required and optional components to design
a redundancy system.
IMPORTANT There are module series level, firmware revision, and software version
requirements for redundancy systems.
For more information on these module series level, firmware revision, and
version requirements, see the current release notes at:
http://www.rockwellautomation.com/global/literature-library/
overview.page
Redundant Chassis You can use any ControlLogix® or ControlLogix-XT™ chassis in a redundant
chassis pair as long as the two chassis that are used are the same size. For example,
if the primary chassis in your redundant chassis pair uses a 1756-A4 chassis, the
secondary chassis must use a 1756-A4 chassis.
• Module type
• Chassis size
• Slot placement
• Firmware revision
0 1 2 3 0 1 2 3
1756-L64
1756-L64
Controllers in Redundant Remember these points when you place controllers in the redundant chassis pair:
Chassis • Controllers are typically included, but not required, in redundancy
systems. If you have a redundancy system without controllers, you have
only a redundant gateway rack.
• You can place up to two controllers in the same chassis. When you use two
controllers in the same chassis, they must be of the same product family.
The series of the controller in the primary and secondary chassis do not
need to match.
• You can use different catalog numbers from the same product family in the
same chassis. For example, you can use two ControlLogix 5560 controllers
in a chassis.
TIP ControlLogix 5580 controllers that are enabled for redundancy do not have
memory constraints.ControlLogix 5580 controllers that are enabled for
redundancy experience no reduction in memory from a standard use
ControlLogix 5580 controller.
• Each controller must have enough I/O memory to store twice the amount
of I/O memory used. To check the I/O memory that is used and available,
access the Memory tab of the Controller Properties dialog box in the
programming software.
For more information about data and I/O memory, see the
Knowledgebase Article Understanding ControlLogix Redundancy Memory
Usage.
• When you use the redundancy system update (RSU) feature to update a
redundancy system while the system continues operation, the updated
controllers must provide the same or greater memory than the existing
controllers.
This table describes the controllers to which you can upgrade, based on the
existing controller that is used, when using RSU.
Differences in controller types between chassis can exist only during the
system upgrade process. When you complete the system upgrade, the
controllers in the redundant chassis pair must match for the system to
synchronize.
If you use the redundant controller at, or very near the connection limits, you can
experience difficulty synchronizing your chassis.
The redundancy modules let you commission the redundant system in a plug-
and-play manner without any programming. You connect a redundancy module
pair with the default configuration in the redundant chassis pair and configure
the redundant system.
• Insert a redundancy module pair into two powered chassis that contain
redundancy-compliant components and redundancy-enabled application
programs, and then connect the redundancy modules.
• Insert and connect the redundancy modules in two chassis and then insert
redundancy-compliant components into each chassis.
IMPORTANT You are not required to develop any programming to migrate from a non-
redundant to a redundancy system if your application meets these
conditions:
• Your application meets the points that are listed in Restrictions on
page 19.
• The controller properties dialog box in your project has Redundancy
enabled.
Once the redundant chassis pair contains all desired components and is powered,
no further tasks are required in the redundancy modules to activate system
redundancy. The redundancy modules automatically determine the operational
state of each of the chassis pair and are ready to accept commands and provide
system monitoring.
• You can use the 1756-EN2TR module only with a redundancy system,
revision 19.052 or later.
• You can use the 1756-EN2F module only with a redundancy system,
revision 20.054 or later.
• You can use the 1756-EN2TP module only with a redundancy system,
revision 31.052 or later.
• If you use a ControlNet network in your redundant chassis pair, you must
have two ControlNet communication modules outside the redundant
chassis pair. When you assign node address numbers, assign the lowest
node number address to a ControlNet communication module outside the
redundant chassis pair.
For more information, see Use at Least Four ControlNet Network Nodes
on page 30 through Assign Lowest Node Numbers to Remote ControlNet
Modules on page 31.
• Program upload
• Three of the 131 CIP connections are reserved for redundancy. The three
redundant-system CIP connections always appear to be in use, even when
no connections are open.
• You can use the remaining 128 CIP connections in any manner that your
application requires, such as the examples listed previously.
• You can use the remaining 256 connections in any manner that your
application requires, such as the examples listed previously.
For more information about redundant power supplies, see the ControlLogix
System Selection Guide, publication 1756-SG001.
EtherNet/IP Networks with The use of EtherNet/IP networks in a redundancy system is primarily dependent
Redundant Systems on your system revision.
IMPORTANT A remote chassis can be accessed over an EtherNet/IP network by using any
EtherNet/IP module that works in a non-redundant chassis with no
additional firmware requirement with the following exception. If the remote
chassis contains a controller that consumes a tag that is produced in the
redundant chassis pair, it can only consume the tag with the required
firmware revisions.
Unicast Functionality
Redundancy systems support unicast produced tags. Unicast consumed tags are
not supported in redundancy systems. Unicast I/O is not supported in a
redundancy system.
These connection types can experience the communication delay when the
switchover occurs:
• HMI to redundant chassis pair
• FactoryTalk® Batch server to redundant chassis pair
• FactoryTalk Alarms and Events Service to redundant chassis pair
IMPORTANT • Prior to firmware revision 30.051, the communication delays apply only
when communication is exclusively over EtherNet/IP networks.
• With firmware revision 30.051 or later, the communication delays apply to
both EtherNet/IP and ControlNet networks.
HMI
EtherNet/IP
ControlNet
ControlNet Networks with ControlNet networks are used to connect redundant controller chassis to remote
Redundant Systems I/O and to other devices in the system.
IMPORTANT A remote chassis can be accessed over a ControlNet network that uses any
ControlNet module that works in a non-redundant chassis with no
additional firmware requirement.
With redundant systems, at least four ControlNet network nodes are required
per ControlNet network. This configuration is required because two or more
ControlNet nodes must be used with the two ControlNet modules that are used
in the redundant chassis. One of the two nodes outside of the redundant chassis
must be at a lower node address than the ControlNet modules in the redundant
chassis.
If your ControlNet uses fewer than four nodes, and a switchover occurs,
connections can drop and outputs connected to that node can change state
during the switchover.
You can include these ControlNet modules and redundant ControlNet nodes:
• ControlNet bridges in remote chassis
• Any other ControlNet devices on the ControlNet network
• A workstation running RSLinx Classic communication software that is
connected via a ControlNet network
• If the entire system loses power, you can be required to cycle power to the
primary chassis to restore communication.
Where ControlNet modules are used as partners in a redundant chassis pair, you
must set the node address switches to the same node address. The primary
ControlNet modules can be at even or odd node addresses.
For example, partnered ControlNet modules with address switches set at 12 are
assigned ControlNet node numbers 12 and 13 by the system.
TIP The primary chassis always assumes the lower of the two node
addresses.
Other Communication You can use only EtherNet/IP and ControlNet networks, and corresponding
Networks modules, in the local chassis for redundancy systems.
IMPORTANT Do not use the redundant chassis to bridge between networks. Bridging
through the redundant chassis to the same or different networks, or
routing messages through redundant chassis is not supported.
This table indicates what system components to use with each network that is
connected to a redundant system.
I/O Placement In a redundancy system, you can place I/O modules in these locations:
IMPORTANT You cannot install I/O modules in the redundant chassis pair. You can only
install I/O modules in remote locations that are accessed over the networks
in this list.
You can connect to remote I/O modules over an EtherNet/IP network in a
redundancy system, revision 19.052 or later.
With a redundancy system revision 19.052 or greater, you can connect to 1715
Redundant I/O systems over an EtherNet/IP network.
The 1715 Redundant I/O system provides high availability and redundancy for
critical processes by using a redundant adapter pair and multiple I/O modules
that have diagnostics and are easily replaceable.
The 1715 Redundant I/O system consists of one, two-slot, adapter base unit that
houses a redundant adapter pair. The adapter base unit is connected to up to 8,
three-slot, I/O base units, which can hold up to 24 fully configurable digital and
analog I/O modules. You can configure a 1715 Redundant I/O system in a Ring
or Star topology.
Each 1715 Redundant I/O system uses one IP address as the primary IP address
for all communication. The redundant adapter pair consists of two active
modules, a primary adapter and its partner, a secondary module.
For more information about the 1715 Redundant I/O system, see the Redundant
I/O System User Manual, publication 1715-UM001.
Workstation
EtherNet/IP EtherNet/IP
1 2 3 4 5 6 7 8 9 10 11 12 25 26 1 4 5 10/100/1000 PoE+ 8 9 12
IN IN
13 14 15 16 17 18 19 20 21 22 23 24 27 28
Disp.
Mode OUT OUT
TOD
EIP Mod
EIP Net
Setup
GPS
TimeCD
1
2
Out
2
Speed
Duplex
PRP
DLR
PoE
GPS ANT. DIG.TimeCode ANA.TimeCode
1
3
4
1 2 3 4 5 6 7 8 9 10 11 12 25 26 1 4 5 10/100/1000 PoE+ 8 9 12
IN IN
13 14 15 16 17 18 19 20 21 22 23 24 27 28
Disp.
Mode OUT OUT
TOD
EIP Mod
EIP Net
Setup
GPS
TimeCD
1
2
Out
2
Speed
Duplex
PRP
DLR
PoE
EtherNet/IP Switches
EtherNet/IP
Bridging Chassis
1715 Redundant I/O
Using HMI Depending on the network that is used to connect the redundant system to
HMIs, plan for certain placement and configuration requirements. You can
connect an HMI to a primary chassis over either of these networks:
• EtherNet/IP
• ControlNet
FactoryTalk View Site Edition software with • Use FactoryTalk Linx communication software, version 5.0 or
FactoryTalk Linx software later.
• Keep the HMI and both redundant chassis on the same subnet.
• Configure the network to use IP swapping.
• FactoryTalk View Site Edition software Limit the number of RSLinx servers that a controller uses to 1…3
with RSLinx Classic software, version 2.52 servers, where the use of one server is ideal.
or later
• RSView®32 software
• Any other HMI client software that uses
RSLinx Classic software, version 2.52 or
later
This table describes redundant system considerations specific to the HMI being
used on the ControlNet network.
• FactoryTalk View Site Edition software Limit the number of RSLinx servers that a controller uses to 1 (ideal)
with RSLinx Classic software, version 2.52 to 3 (maximum).
or later
• RSView32 software
• Any other HMI client software that uses
RSLinx Classic software, version 2.52 or
later
HMI
ControlNet
For an example of how to connect an HMI to a redundant chassis pair over a path
that bridges from an EtherNet/IP network to a ControlNet network, see
Bridge from an EtherNet/IP Network to a ControlNet Network on page 29.
Optional Software Optional software can be needed depending on your redundancy system
program, configuration, and components. Optional software is listed in the
following table.
Notes:
Topic Page
Before You Begin 43
Redundancy System Quick Start 43
Install the Hardware 45
Connect the Redundancy Modules 52
Update Redundant Firmware 58
Designate the Primary and Secondary Chassis 61
Before You Begin Complete these tasks before you install the redundancy system:
• Verify that you have the components that are required to install your
system.
• If you choose to make your own fiber-optic cable for lengths that the
1756-RMCx catalog numbers do not support, refer to Fiber-optic Cable
on page 56.
Redundancy System Quick See these Quick Start steps when configuring your system for the first time.
Start 1. Review the release notes for the firmware bundle that you are installing.
Make sure that you have compatible hardware and the correct firmware
revisions.
2. Install/update the workstation software and firmware bundle.
Software applications that are needed include:
• Studio 5000 Logix Designer® application
• RSLinx® Classic communication software
• Redundancy Module Configuration Tool (RMCT). See Install the
Hardware on page 45
IMPORTANT If RSLinx Classic software is already on your system, make sure to shut it
down before installing/upgrading software.
Install the Hardware Follow these steps to configure and install the hardware components of your
system.
When you install a redundancy system, install one chassis, and its necessary
components, at a time.
The redundancy module pair must occupy the same slots in their respective
chassis. The redundancy module pair does not consider the chassis pair to be
partnered if the redundancy modules are placed in different slots. This outcome
is true even if the partners of other modules are present in the same slot.
IMPORTANT For best performance, place the redundancy module in the chassis as close
as possible to the controller.
Complete these tasks to install the first chassis in the redundant chassis pair:
• Install the Redundancy Module
TIP Do not apply power to the system until both chassis and their components
are installed.
Then follow the steps that are described in Update Redundant Firmware on
page 58 to determine when to power each chassis.
You must install one redundancy module in each chassis that is planned for your
system. Available modules are as follows:
• 1756-RM2
• 1756-RM2XT
• 1756-RM/A
• 1756-RM/B
• 1756-RMXT
IMPORTANT Redundancy bundles version 24.052 and greater support only 1756-RM2 and
1756-RM2XT modules.
Installation Requirements
ATTENTION: This equipment is intended for use in a Pollution Degree 2 industrial environment, in overvoltage
Category II applications (as defined in IEC 60664-1), at altitudes up to 2000 m (6562 ft) without derating.
This equipment is not intended for use in residential environments and may not provide adequate protection to radio
communication services in such environments.
This equipment is supplied as open-type equipment. It must be mounted within an enclosure that is suitably designed for
those specific environmental conditions that will be present and appropriately designed to prevent personal injury
resulting from accessibility to live parts. The enclosure must have suitable flame-retardant properties to prevent or
minimize the spread of flame, complying with a flame spread rating of 5VA or be approved for the application if
nonmetallic. The interior of the enclosure must be accessible only by the use of a tool. Subsequent sections of this
publication may contain additional information regarding specific enclosure type ratings that are required to comply with
certain product safety certifications.
In addition to this publication, see the following:
• Industrial Automation Wiring and Grounding Guidelines, Rockwell Automation publication 1770-4.1, for additional
installation requirements
• NEMA Standard 250 and IEC 60529, as applicable, for explanations of the degrees of protection provided by enclosure
ATTENTION: This equipment is sensitive to electrostatic discharge, which can cause internal damage and affect normal
operation. Follow these guidelines when you handle this equipment:
• Touch a grounded object to discharge potential static.
• Wear an approved grounding wrist strap.
• Do not touch connectors or pins on component boards.
• Do not touch circuit components inside the equipment.
• Use a static-safe workstation, if available.
• Store the equipment in appropriate static-safe packaging when not in use.
WARNING: When you insert or remove the module while backplane power is on, an electrical arc can occur. This could
cause an explosion in hazardous location installations.
Be sure that power is removed or the area is nonhazardous before proceeding. Repeated electrical arcing causes excessive
wear to contacts on both the module and its mating connector. Worn contacts may create electrical resistance that can
affect module operation.
WARNING:
• This equipment must be installed in an enclosure providing at least IP54 protection when applied in Zone 2
environments.
• This equipment shall be used within its specified ratings defined by Rockwell Automation.
• This equipment must be used only with ATEX certified Rockwell Automation backplanes.
• Do not disconnect equipment unless power has been removed or the area is known to be nonhazardous.
ATTENTION: Personnel responsible for the application of safety-related programmable electronic systems (PES) shall be aware
of the safety requirements in the application of the system and shall be trained in using the system.
Optical Ports
ATTENTION: Under certain conditions, viewing the optical port may expose the eye to hazard. When viewed under some
conditions, the optical port may expose the eye beyond the maximum permissible-exposure recommendations.
WARNING: When you insert or remove the small form-factor pluggable (SFP) optical transceiver while power is on, an electrical
arc can occur. This could cause an explosion in hazardous location installations.
Be sure that power is removed or the area is nonhazardous before proceeding.
ATTENTION: Class 1 laser product. Laser radiation is present when the system is open and interlocks bypassed. Only trained and
qualified personnel are allowed to install, replace, or service this equipment.
Side View
Side View
Front View
Front View
Status Indicators
Status Indicators
Redundancy Module
PRI COM OK
LC Single- LC Single-
mode Backplane mode
Connector Connector Connector Backplane
Connector
Bottom View Bottom View
1. Align the circuit board with top and bottom guides in the chassis.
2. Slide the module into the chassis and make sure that the module backplane
connector properly connects to the chassis backplane.
The module is properly installed when it is flush with other installed modules.
IMPORTANT To remove the module, push the locking clips at the top and bottom of each
module and slide the module out of the chassis.
The first chassis and its components are now installed. Chassis power must
remain off.
Once the first chassis and its components are installed, you can install the second
chassis of the redundant chassis pair.
See Install the Redundancy Module on page 45 to install the second chassis.
IMPORTANT The components that are used in the first and second chassis must match
exactly for the system to synchronize.
Connect the Redundancy Once the first and second chassis and their components are installed, you
Modules connect the redundancy modules via the 1756-RMCx fiber-optic
communication cable. The cable is not included with the redundancy module.
Before installation, order this fiber-optic communication cable separately.
IMPORTANT Longer cables can be user-made and are supported based on the optical power
budget of the system. See Fiber-optic Cable on page 56.
ATTENTION: Under certain conditions, viewing the optical port can expose the
eye to hazard. When viewed under some conditions, the optical port can expose
the eye beyond the maximum permissible exposure recommendations.
IMPORTANT The redundancy module communication cable contains optical fibers. Avoid
making sharp bends in the cable. Install the cable in a location where it is
not cut, run over, abraded, or otherwise damaged.
IMPORTANT The redundancy module communication cable contains optical fibers. Avoid
making sharp bends in the cable. Install the cable in a location where it is
not cut, run over, abraded, or otherwise damaged.
Fiber-optic Cable
If you choose to make your own fiber-optic cables, consider the following:
• Fiber-optic Communication Cable Specifications:
The dual fiber ports of the 1756-RM2 module constitute a redundant pair of
communication channels between the partner 1756-RM2 modules in a
redundant chassis pair. One of the channels is termed as 'ACTIVE', while the
other channel is termed as 'REDUNDANT'. All data communication between
the partner redundancy modules is conducted exclusively over the ACTIVE
channel. If or when the ACTIVE channel fails, a 'Fiber Channel Switchover' is
initiated automatically and all data communication shifts to the REDUNDANT
channel, which then becomes the new ACTIVE channel.
Due to the fiber channel switchover, the redundant chassis pair remains
synchronized even after a failure of the ACTIVE channel. Any of the following
failures of the ACTIVE channel trigger an automatic fiber channel switchover to
the REDUNDANT channel, provided the REDUNDANT channel is still
operating in a normal condition:
• Signal attenuation along the fiber cable path that is routed between the
partner redundancy modules
• A broken or damaged fiber cable that is routed between the partner
redundancy modules
• Improper or loosely fit cable connector
• SFP transceiver fault
• Removal or loose connection of the SFP transceiver
• Data communication error (signaled by a failed CRC check)
Chassis synchronization is lost only when both of the channels have failed or are
disconnected.
The fiber channel switchover can occasionally extend the completion of data
communication packets between the partner redundancy modules. Therefore,
the scan time of the controller can occasionally experience a delay of 10 ms or less.
Configuration
The use of dual fiber ports is entirely ‘plug and play’. There is no user
configuration that is needed for any of the operations of the active and redundant
channels. The firmware automatically manages the selection of active and
redundant channels. The dual fiber cables between the partner redundancy
modules can be crossed over between CH1 and CH2 without any restriction.
The status indicators on the front panel and the indicators and counters that are
displayed in the RMCT provide monitoring of the channel status.
Update Redundant Use ControlFLASH or ControlFLASH Plus software to upgrade the firmware
Firmware of each module in each chassis.
IMPORTANT Apply power ONLY to the chassis that contains modules on which you are
upgrading firmware.
Logix 55xx
RUN FORCE SD
OK
3. Wait for the redundancy module to complete its start-up scroll messages.
Check the module’s status indicators. Wait 45 seconds before you begin
updating the 1756-RM/1756-RM2 firmware. During this time, the
redundancy module conducts internal operations to prepare for an update.
Power Supply
indicator is green. Alphanumeric Display Redundancy Module
CH2 CH1 OK
Logix5563 Redundancy Module
5. Select the catalog number of the module (upgrade the redundancy module
first) and click Next.
IMPORTANT The 1756-RM2 module uses different firmware than the 1756-RM and
1756-RMXT modules.
IMPORTANT This process can take a few minutes. The system can look like it is not doing
anything, but it is. When the update is complete, the Update Status dialog
box appears and indicates that the update has successfully completed.
IMPORTANT Power off the first chassis after you have verified a successful update of each
module.
Complete these steps to update the firmware for the modules in the second
chassis.
Designate the Primary and Power on the chassis you want to designate as the primary chassis first. After you
Secondary Chassis have applied power, qualify the system so that all module pairs are at compatible
firmware revision levels.
IMPORTANT Do not apply power to the chassis until you have read the instructions for
designating the primary chassis. Applying power to the chassis in the
correct order is crucial to designating the primary and secondary chassis.
Do not attempt to designate a primary chassis before loading in an
application image.
Before you designate the primary chassis and qualify the system, make
sure that you have the latest firmware installed.
See Update Redundant Firmware on page 58.
IMPORTANT If both modules have power applied to them simultaneously, the module
with the lowest IP address is designated as the primary chassis and displays
PRIM on the four-character display of the module. In addition, the PRI status
indicator on the primary redundancy module is green. The secondary chassis
displays either DISQ or SYNC, depending on the state of the secondary
chassis. In addition, the PRI status light on the secondary redundancy
module is not illuminated.
After Designation
When you first apply power to the designated primary and secondary chassis,
compatibility checks are carried-out between the redundant chassis. Then, if the
Auto-Synchronization parameter is set at Conditional, qualification begins.
TIP While the qualification occurs, the module status display transitions from DISQ
(disqualified) to QFNG (qualifying) to SYNC (synchronized). The qualification s
complete in 1…3 minutes and then module status display indicates the
qualification status.
Use this table as a reference when interpreting the qualification status of the
modules that are displayed on the module status display.
For more information, see Convert from a Non-redundant System on page 219.
For more information on how to use the RMCT, see Chapter 6, Configure the
Redundancy Modules on page 89.
In addition, you can view events specific to qualification in the Event Log of the
RMCT.
IMPORTANT Do not choose to cycle power to the chassis if it causes you to lose control
of your process.
IMPORTANT If you want to resume system operation with an identical module, you
must install the new module in the same slot.
Topic Page
Requested Packet Interval 65
IP Address Swapping 66
CIP Sync 69
Produce/Consume Connections 72
Configure EtherNet/IP Communication Modules in a Redundant System 75
Use a Redundancy System with Device Level Ring 76
Use a Redundancy System with Parallel Redundancy Protocol 77
Requested Packet Interval When using revisions earlier than 20.054, the RPI for I/O connections in a
redundancy-enabled controller tree must be less than or equal to 375 ms. When
using revision 20.054 or later, the RPI can be the same as a non-redundant
chassis.
CPU Usage
IMPORTANT You must use IP address swapping to use remote I/O and produce/consume
connections of an EtherNet/IP network.
If you are using different subnets, you are responsible for programming your
system to use the address and subnet of the new primary chassis in the event of a
switchover.
If you do not use IP address swapping, assign unique values for these
configuration parameters at minimum on both EtherNet/IP communication
modules in the partnered set:
• IP address
IMPORTANT The IP address cannot be of the following format between the partner
EtherNet modules: aaa.bbb.ccc.ddd & aaa.bbb.ccc.(ddd+1)
If you use IP address swapping, assign the same values for these configuration
parameters on both EtherNet/IP communication modules in the partnered set:
• IP address
• Subnet mask
• Gateway address
1756-L64
1756-L64
After you cycle power to the EtherNet/IP communication module, you can
either set the switches on the module to the desired address, or set the switches to
999 and use one of these methods to set the IP address:
• BOOTP-DHCP server
• RSLinx Classic communication software
• Programming software
CIP Sync With redundancy system revision 19.052 or greater, you can use CIP Sync™
technology. CIP Sync technology provides a mechanism to synchronize clocks
between controllers, I/O devices, and other automation products in your
architecture with minimal user intervention.
CIP Sync technology uses Precision Time Protocol (PTP) to establish a Master/
Slave relationship among the clocks for each CIP Sync-enabled component in
the system. One master clock, which is known as the Grandmaster, sets the clock
to which all other devices on the network synchronize their clocks.
IMPORTANT Before you use this enhancement in a redundancy system, revision 19.052 or
later, see these publications for a full understanding of CIP Sync technology
in any system:
• Integrated Architecture™ and CIP Sync Configuration Application
Technique, publication IA-AT003
• ControlLogix® System User Manual, publication 1756-UM001
Consider these points when you use CIP Sync technology in a redundancy
system, revision 19.052 or later:
• While CIP Sync technology can handle multiple paths between master
and slave clocks, it resolves mastership most effectively if you configure the
redundant paths so that Time Synchronization is enabled in only the
minimum required number of EtherNet/IP communication modules.
Figure 19 - Redundancy System, Revision 19.052 or greater, Using CIP Sync Technology
Supervisory
EtherNet
CIP Sync
CIP Sync
M S S M
Primary Chassis Secondary Chassis
P1 P1
G M S
CIP Sync
CIP Sync
CIP Sync CIP Sync
S M M S S S
P2
S S
S S
CIP Sync
CIP Sync CIP Sync
CIP Sync
CIP Sync M S S S
Produce/Consume With redundancy system revision 19.052 or later, you can use produce/consume
Connections connections over an EtherNet/IP network. Controllers let you produce
(broadcast) and consume (receive) system-shared tags.
TIP When using ControlLogix 5570 controllers in your system, you must use
revision 19.053 or greater.
1756-L64
Controller 1
Produced Tag
1756-L64
Controller 2
Consumed Tag
These requirements exist when you use produced and consumed connections
over an EtherNet/IP network in a redundancy system, revision 19.052 or
greater:
• You cannot bridge produced and consumed tags over two networks. For
two controllers to share produced or consumed tags, both must be
attached to the same network.
• Produced and consumed tags use connections in both the controllers and
the communication modules being used.
• Because the use of produced and consumed tags uses connections, the
number of connections available for other tasks, such as the exchange of
I/O data, is reduced.
The number of connections available in a system depends on controller
type and network communication modules used. Closely track the
number of produced and consumed connections to leave as many as
necessary for other system tasks.
• When you add an Ethernet module for the redundancy chassis to the I/O
tree of a remote consuming controller, change the Connection setting
from Rack Optimized to None. If this setting is not changed the
configured connection can briefly drop during a switchover.
The connection from the remote controller to the redundant controller can
briefly drop during a switchover. This condition can occur if the EtherNet/IP
communication modules of the remote chassis do not use specific firmware
revisions. The controllers in the redundant chassis pair must also produce tags
over the EtherNet/IP network that the controllers in the remote chassis consume.
IMPORTANT The minimum firmware revisions that are listed in Table 5 apply only to
EtherNet/IP communication modules in the remote chassis.
In a redundant chassis pair, you can use only the ControlLogix modules that are
listed in the respective bundle's release notes
Configure EtherNet/IP Use these procedures to configure EtherNet/IP communication modules that
Communication Modules in are used in redundant chassis.
a Redundant System
Before You Begin
Use one of these tools to set the IP addresses for your EtherNet/IP
communication modules:
• Rotary switches on the module
• RSLinx Classic communication software
• Programming software
• BOOTP/DHCP utility
Use a Redundancy System Device Level Ring (DLR) is an EtherNet/IP protocol defined by ODVA, Inc.
with Device Level Ring DLR provides a means for detecting, managing, and recovering from single faults
in a ring-based network.
Node Description
Ring supervisor A ring supervisor provides these functions:
• Manages traffic on the DLR network
• Collects diagnostic information for the network
A DLR network requires at least one node to be configured as ring supervisor.
IMPORTANT: By default, the supervisor function is disabled on supervisor-capable
devices, so they are ready to participate on a linear or star network or as a ring node on a
DLR network.
In a DLR network, you must configure at least one of the supervisor-capable devices as
the ring supervisor before physically connecting the ring. If you do not, the DLR network
does not work.
We recommend to assign at least one supervisor outside of the redundant chassis pair to
prevent losing supervision of the DLR during switchover.
For more information on DLR operation see the EtherNet/IP Device Level Ring
Application Technique, publication ENET-AT007.
Ring participants Ring participants provide these functions:
• Process data that is transmitted over the network.
• Pass on the data to the next node on the network.
• Report fault locations to the active ring supervisor.
When a fault occurs on the DLR network, ring participants reconfigure themselves and
relearn the network topology.
Redundant gateways Redundant gateways are multiple switches connected to a single DLR network and also
(optional) connected together through the rest of the network.
Redundant gateways provide DLR network resiliency to the rest of the network.
Depending on their firmware capabilities, both devices and switches can operate
as supervisors or ring nodes on a DLR network. Only switches can operate as
redundant gateways.
For more information about DLR, see the EtherNet/IP Device Level Ring
Application Technique, publication ENET-AT007.
Use a Redundancy System Parallel Redundancy Protocol (PRP) is defined in international standard
with Parallel Redundancy IEC 62439-3 and provides high-availability in Ethernet networks. PRP
technology creates seamless redundancy by sending duplicate frames to two
Protocol independent network infrastructures, which are known as LAN A and LAN B.
Component Description
LAN A and LAN B Redundant, active Ethernet networks that operate in parallel.
Double attached node (DAN) An end device with PRP technology that connects to both LAN A and LAN B.
Single attached node (SAN) An end device without PRP technology that connects to either LAN A or LAN B.
A SAN does not have PRP redundancy.
Redundancy box (RedBox) A switch with PRP technology that connects devices without PRP technology to
both LAN A and LAN B.
Virtual double attached node An end device without PRP technology that connects to both LAN A and LAN B
(VDAN) through a RedBox.
A VDAN has PRP redundancy and appears to other nodes in the network as a DAN.
Infrastructure switch A switch that connects to either LAN A or LAN B and is not configured as a RedBox.
For more information about PRP topologies and configuration guidelines, see
the EtherNet/IP Parallel Redundancy Protocol Application Technique,
publication ENET-AT006.
Notes:
Topic Page
Produce/Consume Connections 79
Network Update Time 81
Scheduled or Unscheduled Network 83
Schedule a New Network 84
Update an Existing Scheduled Network 87
Check the Network Keeper States 88
Controller 1
Produced Tag
Controller 2
Consumed Tag
Keep these points in mind when you use produced and consumed connections
over a ControlNet network in a redundancy system:
• During a switchover, the connection for tags that are consumed from a
redundant controller can drop briefly.
After the switchover, the connection is re-established and the data begins
to update again.
• You cannot bridge produced and consumed tags over two networks. For
two controllers to share produced or consumed tags, both must be
attached to the same network.
• Produced and consumed tags use connections in both the controllers and
the communication modules being used.
• Because the use of produced and consumed tags uses connections, the
number of connections available for other tasks, such as the exchange of
I/O data, is reduced.
Network Update Time The network update time (NUT) that you specify for your redundant system
affects your system performance and your switchover response time. Typical
NUTs used with redundant systems range from 5…10 ms.
You can choose to use multiple ControlNet networks with your redundancy
system.
1756-L63
ControlNet Network 1
NUT = 5 ms
ControlNet Network 2
NUT = 21 ms
When you use multiple ControlNet networks, the networks must use compatible
NUTs. Compatible NUTs are determined based on the network that uses the
smallest NUT.
• Add any remote I/O besides ControlLogix I/O. For example, if you add
FLEX™ I/O modules, you must schedule the network.
• Add a remote I/O chassis of ControlLogix I/O that does not use the
Rack Optimized communication format. That is, direct connections to
the I/O are used.
You can add those components to the unscheduled network while your
redundant system is online and in Run mode. We recommend that you do not
use an unscheduled network for all of your I/O connections.
• For each remote I/O module used, plan for one direct connection to be
used.
Schedule a New Network Complete these steps to schedule a new ControlNet network for a redundancy
system.
IMPORTANT Before you schedule a ControlNet network, turn on the power to both
redundant chassis.
If you schedule a ControlNet network while the secondary chassis is off,
the keeper signature of a 1756-CN2 or 1756-CN2R module can mismatch
its partner. This action can cause the secondary chassis to fail to
synchronize.
Parameter Specify
Network Update Time (ms) The minimum repetitive interval when data is sent over the ControlNet
network.
Max Scheduled Address The highest node number that uses scheduled communication on the
network.
Max Unscheduled Address The highest node number that you use on the network.
Media Redundancy The ControlNet channels that you are using.
Network Name A name for identifying the ControlNet network.
10. On the Media Configuration tab, add repeaters, fiber, and coax to
accurately represent your the worse case path between any two ControlNet
nodes.
Update an Existing If you are adding the redundant chassis to an existing ControlLogix system that
Scheduled Network uses a ControlNet network, complete these steps to update the existing
ControlNet network.
9. Click OK.
10. From the Network menu, choose Single Pass Browse.
11. From the File menu, choose Save.
12. Click Optimize and rewrite schedule for all connections and click OK.
Check the Network Keeper After you schedule your ControlNet network, check the states of keeper-capable
States nodes. Checking the status of keeper-capable nodes is important because if a
major network disruption occurs, the keepers provide network configuration
parameters that are required to recover.
To check the status of keepers on the ControlNet network, complete these steps.
4. Verify that all nodes on the network have the same keeper signature.
After you have scheduled your ControlNet networks, go online with each
controller in your primary chassis, and upload and save the project. This process
makes downloading a project easier in the future because you won’t be required
to reschedule the network after completing the download.
To replace a ControlNet module that has been configured and scheduled on the
ControlNet network, remove the existing module and insert a
1756-CN2, 1756-CN2R, or 1756-CN2RXT module. The module that you are
inserting must be unconfigured or have a keeper signature of all zeros.
Topic Page
About the Redundancy Module Configuration Tool (RMCT) 91
Determine If Further Configuration Is Required 92
Use the RMCT 93
Module Info Tab 96
Configuration Tab 98
Synchronization Tab 101
Synchronization Status Tab 104
System Update Tab 105
About the Redundancy The Redundancy Module Configuration Tool (RMCT) is used to configure the
Module Configuration Tool redundancy modules and to determine the status of the redundancy system.
You can also use this functionality available with the RMCT to determine the
status of the redundant system:
• View error diagnostics specific to redundant chassis.
• View qualification and compatibility status of partnered modules.
• Identify noncompliant modules for removal.
• View redundant system event history.
Determine If Further The default configuration of the redundancy modules lets you synchronize your
Configuration Is Required redundant chassis without additional configuration if you are using a basic
redundant chassis pair.
However, some applications and uses of the redundancy system can require
additional configuration. For example, you must use the RMCT for additional
configuration if you must complete any of these tasks:
• Set the redundancy modules to a different time or date (recommended).
TIP If you set the time and date of a redundancy module per the workstation time
and date, it can be helpful in analyzing redundancy logs in the future.
If you must complete any of these tasks, see the sections that follow.
Use the RMCT To access and begin using the RMCT, launch RSLinx® Classic software and
browse to your redundancy module. Right-click the redundancy module and
choose Module Configuration.
TIP If you cannot see the Module Configuration option in the list, then the
compatible version of the RMCT is not installed.
When you access the RMCT, the dialog box always indicates the status of the
redundancy chassis in the bottom-left corner.
You must use a version of the RMCT that is compatible with your redundancy
module firmware.
Beginning with version 20.054, the redundancy module firmware reports back to
the Redundancy Module Configuration Tool (RMCT) as to which version of
the RMCT is compatible. If there is an incompatibility, the RMCT shows only
the Module Info tab and indicates the version that the firmware is compatible
with.
To find the latest firmware bundle on the website, follow these steps.
Complete these steps to check or verify the version of the Redundancy Module
Configuration Tool (RMCT) that you have installed.
TIP The RMCT launches at the version that is compatible with the 1756
redundancy module firmware that is installed.
If you have not updated your 1756 redundancy module firmware after
upgrading your RMCT version, the RMCT version that is indicated can
differ from version you updated to. You can also check the RMCT version
that you have installed by using Add or Remove Programs in the Control
Panel.
The About dialog box opens and indicates the RMCT version.
This should show the version you need based on your bundle or higher.
The RMCT always shows the latest version installed, and later versions are
backwards compatible with earlier versions.
The RMCT version that is compatible with your redundancy module firmware is
included in the downloads for most redundancy bundles.
• For redundancy bundles that use firmware revision 20.009 or later for
1756-RM2 modules, the RMCT is included in the redundancy bundle
and is not available for separate download.
• For redundancy bundles that use firmware revision earlier than 20.009,
you can download the RMCT separately as a product add-on.
To launch the installation of the RMCT, open the folder that contains the
redundancy firmware revision and double-click the executable file titled
Redundancy_Module_CT.exe.
The RMCT Installation Wizard opens and prompts you with the steps to install
the RMCT.
Module Info Tab The Module Info tab of the RMCT provides a general overview of the
identification and status information of the redundancy module. This status
information is updated approximately once every two seconds.
TIP Not all indicators are shown for 1756-RM/A and 1756-RM/B modules.
In addition, you can click Change to edit the User-Defined Identity parameters
to meet your application needs.
Configuration Tab Use the Configuration tab to set redundancy options and the internal clock of
the redundancy module. After you modify a parameter, the Apply Workstation
Time button becomes active.
Auto-synchronization
Use the following table to determine the Auto-Synchronization setting that best
suits your application.
Chassis ID
The chassis ID parameter is used to assign a generic label to the chassis that house
the redundancy modules. The available chassis labels are Chassis A and Chassis B.
If you change the chassis label in the RMCT of the primary redundancy module,
the secondary module and chassis are automatically assigned the other chassis
label.
The chassis label that is assigned to the module remains associated with the same
physical chassis, regardless of its primary or secondary control designation.
Check Enable User Program Control in the Configuration tab if you plan to use
MSG instructions in your controller program to initiate a switchover, change the
redundancy module time, or synchronize.
If you leave Enable User Program Control unchecked, the redundancy modules
do not accept any commands from the controller.
The Redundancy Module Date and Time parameters can be applied separate
from the Redundancy Module Options parameters. The time that is specified
with these parameters is the time that the event logs reference when a redundant
system event occurs.
To change the redundancy module time settings, use the pull-down menu or type
your changes then click Set to implement time changes. Or, to set the time of the
redundancy module to match that of the workstation, click Apply Workstation
Time.
IMPORTANT We recommend that you set the redundancy module date and time when
you commission a system. We also recommend that you periodically check
the date and time settings to make sure that they match the settings of the
controller.
If a power failure occurs on the redundant chassis, you must reset the date
and time information of the redundancy modules. The modules do not
retain those parameters when power is lost.
Synchronization Tab The Synchronization Tab has commands for these options:
• Change the synchronization state of the system (synchronize or disqualify)
• Initiate a switchover
• Force the disqualified secondary to become the primary
This tab also has information about the last four synchronization attempts in the
Recent Synchronization Attempts log. N or N-X identify synchronization
attempts in the log. If the redundant chassis fail to synchronize, a cause is
identified in the Recent Synchronization Attempts log.
The causes and their interpretations are described in the Recent Synchronization
Attempts Log section on page 103.
These sections explain each redundancy command and the system conditions
that are required for the command to be available.
Command Description
Synchronize Secondary This command forces the primary redundancy module to attempt synchronization with its partner. This command is
available in specific conditions:
• Available only when the chassis redundancy state is as follows:
– Primary with Disqualified Secondary
– Disqualified Secondary
• Unavailable (dimmed) in all other chassis states
Synchronization is asynchronous with the execution of this command. Successful execution of this command begins with
synchronization, which can take several minutes. Monitor the chassis status that is displayed at the bottom of the RMCT
to determine when synchronization has completed.
Disqualify Secondary This command forces the primary redundancy module to disqualify its partner.
ATTENTION:
• Disqualifying the secondary chassis makes it unable to assume control functions, that is,
redundancy is lost.
• If you disqualify the secondary and a major fault occurs on the remaining primary, a switchover
does not occur.
This table describes the possible result and causes of synchronization states.
Synchronization Status Tab The Synchronization Status tab provides a module-level view of these items:
System Update Tab Use of the commands in the System Update tab lets you perform firmware
updates in the secondary chassis while the primary chassis remains in control.
Reference the lock and switchover logs in this tab for update information when
completing a firmware update.
The three system update commands are available only when accessing a primary
redundancy module. These commands are not available when accessing the
secondary redundancy module.
TIP While you are completing tasks to update the system by using the
system update commands, you cannot access these tabs in the RMCT:
• Configuration
• Synchronization
• Synchronization Status
If you attempt to access any of these tabs while the system is locked or is
completing a locked switchover, it results in an error dialog box.
The Lock for Update command lets you synchronize a redundant chassis pair
under these conditions:
The Lock for Update command is available only when all modules in the primary
chassis have no compatibility anomalies. Before issuing the lock command, verify
that you have completed these tasks:
For details about how to complete those tasks, see Update Redundant Firmware
on page 58.
Click the Lock for Update command to initiate the locking process. The lock can
take several minutes to finish. Monitor the System Update Lock Attempts log to
determine when the lock is complete. In addition, the chassis status that is shown
at the bottom-left of the dialog box changes from Primary with Disqualified
Secondary to Primary Locked for Update.
Lock initiated.
Lock complete.
Lock complete.
The Abort System Lock command can be used to stop the system lock. It is
available as soon as a lock for update is initiated.
Click Abort System Lock to return the redundant chassis status to Primary with
Disqualified Secondary. This action also causes the system update to stop and the
program in the secondary controller to clear. If you click Abort System Lock, you
must download the program to the secondary controller before reattempting a
Lock for Update.
The Initiate Locked Switchover command is available only when the chassis
redundancy state is Primary with Locked Secondary. That is, the Initiate Locked
Switchover is available only after the lock for update is complete.
If you click Initiate Locked Switchover, your secondary chassis assumes control
and becomes the new primary. The old primary is now the new secondary chassis
and you can update the firmware of the modules in the new secondary chassis.
Chassis A Chassis B
CH2 CH1 OK
CH2 CH1 OK
Secondary
1756-L63
1756-L63
1756-L63
1756-L63
Primary
Chassis B Chassis A
1756-L63
1756-L63
1756-L63
1756-L63
Primary
The difference between a locked switchover and a normal switchover is that you
initiate the locked switchover. You or a fault in the primary chassis initiate a
normal switchover.
The System Update Lock Attempts is where attempts to lock the system are
logged. This log displays the last four lock attempts and provides this information
specific to each attempt:
• Time and date
• Status (for example, Locked or Abort)
• Result (for example, System Locked or Invalid Response Received)
The status indicated in the System Update Lock Attempts log can be any one of
the states that are listed in Table 10.
For more information on Lock for Update Failures, see the Knowledgebase
Article Lock for Update Fails.
The Locked Switchover Attempts log provides information about the status of
the last four locked switchover attempts. This log includes this information about
each attempt:
• Time and date
• Status
• Result
The status indicated in the Locked Switchover Attempts log can be any one of the
states that are listed in Table 11.
Topic Page
Configure the Redundant Controller 112
Crossloads, Synchronization, and Switchovers 116
Crossloads and Scan Time 121
Program to Minimize Scan Times 123
Program to Maintain Data Integrity 130
Optimize Task Execution 134
Conduct a Test Switchover 139
Program Logic to Run After a Switchover 141
Use Messages for Redundancy Commands 142
Set the Task Watchdog 146
Download the Project 148
Store a Redundancy Project to Nonvolatile Memory 149
Online Edits 152
Configure the Redundant Both controllers in the ControlLogix® redundancy system operate by using the
Controller same program. You do not need to create a project for each controller in the
redundant system.
IMPORTANT When programming your redundancy system, you should only interface with
the controller in the primary rack unless a specific workflow dictates that the
controller in the secondary rack should be the target of modification.
7. Click Apply.
8. Click OK.
You have completed the minimum configuration that is required for your
redundant controllers.
Enable Time Time synchronization is not required for redundancy to function. If your
Synchronization application requires Time synchronization, then follow these steps.
2. Click Apply.
3. Click OK.
4. Access the Module Properties dialog box for the Ethernet module.
5. At the General tab of the Module Properties dialog box of the Ethernet
module, click Change.
6. In the Module Definition dialog box from the Time Sync connection pull-
down menu, select Time Sync and Motion.
Crossloads, Crossloading and synchronization points are points where the primary controller
Synchronization, and transfers data to the secondary controller. Crossload and synchronization points
keep the secondary controller ready to assume control in the event of a fault on
Switchovers the primary.
Before you begin programming your redundant controller, be aware of the impact
of crossloads and synchronization on the execution of a program after a
switchover. If you understand these concepts, it helps you to create programming
that best meets the needs for your redundant application.
Continue reading the sections that follow for explanations of crossloads and
synchronization and their relationship to switchovers and program execution.
If you reduce the number of crossload and synchronization points, the switchover
time becomes longer. This increase in switchover time is because more programs
can be rescanned after the switchover.
Synchronization is performed at the end of the last program in the program list of
the task, regardless of the Synchronize Data after Execution setting for the
program.
Before you change the default crossload and synchronization settings, read the
sections that follow so you have a complete understanding of the implications.
For information about how to change the point in a task where a crossload
occurs, see Changing Crossload and Synchronization Settings on page 116.
To avoid anomalies after a switchover occurs, we recommend that you use only
one of these task configurations when programming your redundant controllers.
Use either of the following:
• One continuous task
• Multiple periodic tasks, each with unique priorities and periods
Only the single highest-priority periodic task can ensure bumpless output
switching on switchover. The sections that follow explain the impact of
crossloads and synchronization after a switchover based on the task structure you
use.
Figure 26 - Program Execution After a Switchover (no Crossload After each Program)
New Primary Controller
Program 2 Program 3 Program 1
Switchover
Primary Controller
Program 1 Program 2 Program 3
Crossload Crossload
For information about how to change the point in a task where a crossload
occurs, see Changing Crossload and Synchronization Settings on page 116.
In a project where multiple periodic tasks are used, the point where program
execution begins after a switchover depends on the following:
• Crossload and synchronization settings
• Task priority settings
As with the continuous task, the controller begins executing at the program that
follows the last crossload and synchronization point.
The following diagram shows a lower priority task that has not been completed
and a switchover occurs. The lower priority task and programs are executed from
the beginning of the program where the switchover occurred. This result is
because the program uses the default configuration and crossloads and
synchronization points occur at the end of each program.
Figure 28 - Periodic Task Execution After Switchover When Configured to Crossload After
Programs
New Primary
Task - Priority 1
Program 1 Program 2 Program 3
Task - Priority 2
Crossload Program 2 Program 3
Crossload
Task - Priority 1
Program 2 Program 3 Crossload
Crossload Switchover
Task - Priority 2 Task - Priority 2
Primary
Higher-priority Lower-priority
Task Interrupts Task Resumes Crossload
The following diagram shows a lower priority task that has not been completed
and a switchover occurs. The lower priority task and programs are executed from
the beginning and not at the program where the switchover occurred. This result
is because the crossloads and synchronization points were not configured to
occur at the end of each program.
Figure 29 - Periodic Task Execution After Switchover When Configured Not to Crossload After
Programs
New Primary
Higher-priority Lower-priority
Task Interrupts Task Resumes Crossload
For more information about programs and tasks with controllers, see the Logix
5000 Controllers Tasks, Programs, and Routines Programming Manual,
publication 1756-PM005.
Crossloads and Scan Time It is important to plan for controller crossloads because the length of the
crossloads affects the scan time of your program. A crossload is a transfer of data
from the primary controller to the secondary controller. The crossload can occur
at the end of each program or at the end of the last program in a task.
The scan time of your program or phase is a total of the program execution time
and the crossload time. The following diagram demonstrates this concept.
The amount of time that is required for a crossload is primarily dependent upon
the amount of data being crossloaded. During a crossload, any tag that has been
written to during the program execution is crossloaded. Even if a tag has not
changed, but has been rewritten during the program execution, it is crossloaded.
The crossload requires time to transfer tag value changes. The crossload also
requires a small amount of overhead time to communicate information about the
program being executed
Before you complete calculations to estimate the crossload time, you must use a
Get System Value (GSV) instruction to read certain attributes of the redundancy
object. These attributes are data transfer sizes that are measured in DINTs (4-byte
words) and are used to calculate the estimated crossload time.
TIP To get these attributes, you do not need to have the secondary chassis
installed or operating. If you do not have the secondary chassis
operating, the attribute values read indicate what data sizes would be
transferred if the secondary chassis was in use.
This table indicates the two attributes that you can choose to get specific to the
crossload data transfer size. Get the attribute value that meets your application
requirements.
If you must measure the crossloaded data from the last program in the program
list of the task, add an additional program at the end of the task that acquires the
LastDataTransferSize value from the program that was formerly at the end of the
task.
Use this equation to estimate the crossload time of your controllers for each
program after you have either of the following:
• The size of the last data transfer
• The maximum size of data that is transferred
TIP A sync point is a mechanism that the primary controller uses to keep the secondary controller in sync.
By default, at the end of each program scan, the primary controller sends the secondary controller
the sync point and the secondary controller responds by moving its execution pointer to match the
primary controller.
The default for phases is not to send a sync point.
In revision 16.05x and later, the option exists to manipulate the sync points for faster program execution.
Program to Minimize Scan There are several aspects of your program that must be as efficient as possible to
Times facilitate the fastest possible switchover because total program scan time impacts
system switchover time. The sections that follow describe methods to make your
program more efficient to minimize your program scan time.
These methods make your program more efficient and minimize program scan
times:
• Use a ControlLogix 5570 Controller with a 1756-RM2 Redundancy
Module
• Use Multiple Controllers
• Minimize the Number of Programs
• Manage Tags for Efficient Crossloads
• Use Concise Programming
In redundancy system revision 19.053 and later, you can use ControlLogix 5570
controllers in your application. Relative to the redundancy module being used,
the ControlLogix 5570 controllers scan the controller program faster than
ControlLogix 5560 controllers. The ControlLogix 5570 controllers also scan the
controller program fastest if the redundancy system uses the 1756-RM2/A
redundancy module.
IMPORTANT Only the 1756-L72, 1756-L73, 1756-L74, and 1756-L75 controllers can be
used with the 1756-RM2 redundancy modules and revision 19.053.
(1) PlantPAx guidelines recommend only one controller per ControlLogix redundancy chassis. Non-PlantPAx ControlLogix 5570
redundancy applications support as many as two controllers in each redundant chassis
If you must crossload data at the end of each program, make these programming
considerations to minimize the crossload impact on the program scan time:
• Divide each program into the number of routines that is appropriate for
your application. A routine does not cause a crossload or increase the scan
time.
• Use the main routine of each program to call the other routines of the
program.
• If you want to use multiple tasks for different scan periods, use only one
program in each task.
Figure 31 - Use of Multiple Routines (preferred) Figure 31 - Use of Multiple Programs (not
preferred)
Manage your data tags as the following sections recommend to program for more
efficient crossloads of data and reduce the amount of time that is required for a
crossload to execute.
If you delete unused tags, it reduces the size of the tag database. A smaller
database takes less time to crossload.
If you use arrays and User-Defined Data Types, the tags use smaller 4-byte
(32-bit) words for all data in the type or array. If you create an individual tag, the
controller reserves 4 bytes (32 bits) of memory even if the tag uses only 1 bit.
Arrays and User-Defined Data Types help conserve the most memory with
BOOL tags. However, we also recommend that you use them for your SINT,
INT, DINT, REAL, COUNTER, and TIMER tags.
TIP If you have already created individual tags and programming that uses
those tags, consider changing the individual tags to alias tags that
reference the elements in an array.
If you choose this method, your programming can still reference the
individual tag names, but the crossload transfers the base array.
For more information about how to work with arrays, User-Defined Data Types,
and alias tags, see the Logix 5000 Controllers I/O and Tag Data Programming
Manual, publication 1756-PM004.
When you create a User-Defined Data Type for use in your redundancy program,
group like data types together. Grouping like data types compresses the data size
and helps reduce the amount of data that is transferred during a crossload.
To update the secondary controller, the primary controller divides its memory
into blocks of 256 bytes. Anytime an instruction writes a value, the primary
controller crossloads the entire block that contains the value. For example, if your
logic writes only 1 BOOL value to a block, the controller crossloads the entire
block (256 bytes).
To minimize crossload time, group your data by how frequently your program
uses it.
For example, if your application uses DINTs that you use only as constants to
initialize your logic, BOOLs that you update every scan, and REALs that you
update every second, you can create a separate User-Defined Data Type for each
type of tag that is used at different points in the application. Using separate User-
Defined Data Types for each group, rather than grouping all tags together in one
User-Defined Data Type, helps to minimize the amount of data that is transferred
during the crossload.
Tags Grouped into User-Defined Data Types by Frequency of Use Tags in One User-Defined Data Type
We recommend that you use the DINT data type instead of the SINT or INT
data types because the controller usually works with 32-bit values (DINTs or
REALs). When processing, the controller converts SINT or INT tag values to
DINT or REAL values. When processing is complete, the controller converts the
value back to a SINT or INT value.
The controller automatically converts these data types while executing and
processing a program. No additional programming is required. However, while
this conversion process is transparent to you, it does require additional processing
time that impacts your program scan time and your switchover time.
We recommend that you execute instructions only when needed because each
time an instruction writes a value to a tag, the tag is crossloaded to the secondary
controller. Even if the tag values is the same, it is rewritten and is therefore
crossloaded.
Because many instructions write tag values whenever executed, strategic and
economical use of instructions is needed. Strategic programming techniques
include the following:
• Using preconditions to limit the execution of instructions
• Combining preconditions when possible
• Dividing programming into subroutines that are called only when required
• Running noncritical code every 2 or 3 scans instead of during every scan
For example, precondition an ADD instruction to run only when the controller
gets new data. As a result, the Dest_Tag is crossloaded only when the ADD
instruction produces a new value.
Program to Maintain Data When programming your redundant controllers, there are some instructions and
Integrity techniques that can cause data loss or corruption when used. These instructions
and techniques include the following:
• Array (File)/Shift Instructions
• Scan-dependent Logic
The following Array (File)/Shift instructions can result in corrupt data in the
event of a switchover:
• Bit Shift Left (BSL)
• Bit Shift Right (BSR)
• FIFO Unload (FFU)
If Array (File)/Shift Instructions are used, these system behaviors can result:
The programming example that is shown here shows the use of a COP
instruction to move data into a buffer array. The BSL instruction uses the data in
that buffer array. The CPS instruction updates the array tag and maintains data
integrity because a higher priority task cannot interrupt it. If a switchover occurs,
the source data (that is, the array tag) remains unaffected.
For more information about BSL, BSR, FFU, COP, and CPS instructions see the
Logix 5000 Controllers General Instructions Reference Manual,
publication 1756-RM003.
Scan-dependent Logic
When the lower priority task is executed from the beginning by the new primary
controller after the switchover, the dependent instruction can fail to execute at
the most recent value or state.
For example, if a higher priority task interrupts the logic that is shown in this
example, the value of scan_count.ACC is sent to the secondary controller at the
end of the program in the higher priority task. If a switchover occurs before the
primary controller completes the EQU instruction, the new primary controller
starts its execution at the beginning of the program and the EQU instruction
misses the last value of scan_count.ACC. As a result, any programming that uses
the Scan_Count_Light tag can also execute by using incorrect data.
Switchover
Interrupt by higher
priority task.
An Equal To instruction uses the accumulated scan_count value as a reference to turn on an indicator when the
thousandth scan is complete.
For example, if you bind the scan-dependent logic that is previously shown, a
higher priority task would not interrupt the dependent instructions and a
switchover would not result in inconsistent data.
For more information about UID and UIE instructions, see the Logix 5000
Controllers General Instructions Reference Manual,
publication 1756-RM003.
Optimize Task Execution To make synchronization, crossloads, and HMI updates as fast as possible,
consider following these task-related best practices:
• Use periodic tasks; avoid using a continuous task.
• Use the fewest number of tasks possible.
Table 14 lists some of the different communication types that take place during
task execution and service communication periods.
If you have one or more periodic tasks with no continuous task, you can increase
the time dedicated to service communication by adjusting the priority and period
of each periodic task. If you do not have a continuous task in your project,
changing the System Overhead Time Slide has no affect.
TIP While you can use multiple periodic tasks in your redundant controller
program, use the fewest number of tasks possible.
If you use periodic tasks, communication is serviced any time that a task is not
running. For example, if you configure your task period at 80 ms and the task
executes in 50 ms, the controller has 30 ms out of every 80 ms to service
communication.
In this example, the execution time of the highest priority task (Task 1) is smaller
than its period. 20 ms is less than 80 ms. The total execution time of all tasks is
less than the specified period of the lowest priority task. 50 ms is less than 180 ms.
You must tune the period you specify for your periodic tasks to balance the
controller time dedicated to program execution versus servicing communication.
TIP The crossloading of data during synchronization points extends task scan
times in redundancy systems. We recommend that you balance program
execution and service communication when the system is synchronized.
To check for overlaps, go online with the controller and access the Task
Properties dialog box. In the Monitor tab, note the maximum scan time. Verify
that the maximum scan time is smaller than the period you specified for the
periodic task.
If your project only contains a continuous task with no other tasks, you can adjust
the System Overhead Time Slice setting to change the percentage of time the
controller devotes to servicing communication versus executing the continuous
task.
IMPORTANT If there is no continuous task, adjusting the System Overhead Time Slice setting
has no effect. When there is no continuous task, all controller time not used for
other tasks will be used for servicing communications.
Table 16 shows the ratio between executing the continuous task and servicing
communication at various system overhead time slices. Consider the following:
• When the system overhead time slice setting is between 10% and 50%, the
time that is allocated for servicing communication is fixed at 1 ms. The
continuous task time slice changes to produce the desired ratio.
• When the system overhead time slice is greater than 50…90%, the time
that is allocated to the continuous task is fixed at 1 ms. The time that is
allocated to servicing communication changes to produce the desired ratio.
This diagram illustrates a system where the system overhead time slice is set to
20% (default). With this percentage, communication is serviced after every 4 ms
of continuous task execution. Communication is serviced for up to 1 ms before
the continuous task is restarted.
1 ms 1 ms 1 ms 1 ms 1 ms
Service Communication
4 ms 4 ms 4 ms 4 ms 4 ms
Continuous Task
This diagram illustrates a system where the System Overhead Time Slice is set to
33%. With this percentage, communication is serviced after every 2 ms of
continuous task execution. Communication is serviced for up to 1 ms before the
continuous task is restarted.
To change the System Overhead Time Slice, access the Controller Properties
dialog box and click the Advanced tab. From this tab, you can enter your System
Overhead Time Slice value.
Enable the Run Continuous Task option (default setting) if you want the
controller to revert to running the continuous task as soon as the communication
servicing task has no pending activity. This setting results in only using the
allocated communication servicing time if there is a need for it.
IMPORTANT We do not recommend that you use the Reserve for System Task option for
production. The option was developed to simulate systems with high
communication requirements.
Use the Reserve for System Task option to allocate the entire 1 ms of the system
overhead time slice to service communication - even if no service communication
or background tasks must be executed. You can choose to use this option without
service communication or background tasks to simulate a communication load
on the controller during design and programming. Use this setting for testing
only.
Conduct a Test Switchover Complete these steps to verify that your redundant system switches over as
expected. Your system must be fully qualified before you begin.
4. Click Yes.
To monitor the synchronization of your system after you initiate the test
switchover, you can monitor the synchronization process by using these methods:
• Click the Synchronization Status tab and monitor the
Secondary Readiness column. The states No Partner, Disqualified,
Synchronizing, and Synchronized indicate the stages of synchronization.
• View the module status display of a primary communication module. The
states PwNS, PsDS, PwQg, and PwQS indicate the stages of
synchronization.
• View the module status display of the secondary redundancy module. The
states DISQ, QFNG, and SYNC indicate the stages of synchronization.
• Run a second test switchover where you power off the primary chassis to
initiate the switchover.
Program Logic to Run After If your application requires certain logic or instructions to be executed after a
a Switchover switchover, then use programming and tags similar to the values shown in this
example.
This GSV instruction obtains the chassis ID of the primary chassis (that is, the chassis that is in control).
If this is the first program scan, then use the current primary chassis ID as the chassis ID for the last scan.
If a switchover occurs, the chassis ID changes. The NEQ instruction compares the current and last primary chassis ID values. If the
values are different, the Switchover_Occurred bit is turned on. In addition, the current primary chassis ID is moved into the last
chassis ID.
If the Switchover_Occurred bit is on, then the instructions added to this rung are executed and the Switchover_Occurred bit is
reset.
Use Messages for For some applications, consider programming the controller to issue redundancy
Redundancy Commands system commands via the redundancy modules. The sections that follow explain
how to configure a MSG instruction to issue a redundancy command.
For a MSG instruction to issue a command via the redundancy modules, the
redundancy modules must be configured for user program control.
To verify that the modules are enabled for user program control, access the
Configuration tab of the RMCT and verify that Enable User Program Control is
checked.
When you add your MSG instruction for issuing the command through the
redundancy modules, configure it as an unconnected message.
Use the MSG configuration settings that correspond to the command you intend
to issue to the redundancy modules.
Initiate a Switchover
To initiate a switchover, use the MSG instruction parameters that are listed in
Table 17.
Table 17 - MSG Instruction to Initiate a Switchover
In this tab Edit this element To use this value
Configuration Message Type CIP™ Generic
Service Type Custom
Service Code 4e
Class bf
Instance 1
Attribute None - no value needed
Source Element INT tag with a value of 1
Source Length 2
Destination Element None - no value needed.
Communication Path 1 - the slot number of the 1756-RM, 1756-RM2,
1756-RMXT, or 1756-RM2XT module.
Connected box Leave the Connected checkbox unchecked.
• Cached and connected messages cause the message instruction to pause for 7.5 seconds because the initiating controller has
not received a response from the targeted controller. For cached messages, the message instruction tries to execute three more
times, each attempt followed by a pause of 7.5 seconds. If, after 30 seconds pass, the targeted controller does not respond to the
initiating controller, then the switchover errors out with connected timeout Error 1 Extended Error 203.
An example of a connected message would be CIP data table read-and-write messages after a
connection has been established.
• Uncached messages error out after 30 seconds if you have initiated them because the initiating controller never received a reply
to the forward-open request. The error is Error 1F Extended Error 204, an unconnected timeout.
Examples of uncached messages would include CIP generic messages and messages that are captured during the
connection process.
During qualification Cached messages that run with no errors. A connection has been established.
Connected, but uncached, messages or unconnected messages error out with Error 1 Extended Error 301, No
Buffer Memory.
To disqualify the secondary chassis, use the MSG instruction parameters that are
listed in Table 19.
Table 19 - Disqualify the Secondary Chassis
In this tab Edit this element To use this value
Configuration Message Type CIP Generic
Service Type Custom
Service Code 4d
Class bf
Instance 1
Attribute None - no value needed
Source Element INT tag with a value of 1
Source Length 2
Destination Element None - no value needed.
Communication Path 1 - the slot number of the 1756-RM, 1756-RM2,
1756-RMXT, or 1756-RM2XT module.
Connected box Leave the Connected checkbox unchecked.
To disqualify the secondary controller, use the MSG instruction parameters that
are listed in Table 20.
Table 20 - Synchronize the Secondary Chassis
In this tab Edit this element To use this value
Configuration Message Type CIP Generic
Service Type Custom
Service Code 4c
Class bf
Instance 1
Attribute None - no value needed
Source Element INT tag with a value of 1
Source Length 2
Destination Element None - no value needed.
Communication Path 1 - the slot number of the 1756-RM, 1756-RM2,
1756-RMXT, or 1756-RM2XT module.
Connected box Leave the Connected checkbox unchecked.
To set the WallClockTime of the 1756-RM module, use the MSG instruction
parameters that are listed in Table 21.
Table 21 - Set WallClockTime
In this tab Edit this element To use this value
Configuration Message Type CIP Generic
Service Type Custom
Service Code 10
Class 8b
Instance 1
Attribute b
Source Element WallClockTime[0]
WallClockTime is a DINT[2] array that stores the
CurrentValue of the WallClockTime object
Source Length 8
Destination Element None - no value needed.
Communication Path 1 - the slot number of the 1756-RM, 1756-RM2,
1756-RMXT, or 1756-RM2XT module.
Connected box Leave the Connected checkbox unchecked.
Set the Task Watchdog Watchdog times set for tasks in redundancy applications must be larger than
watchdog times set for tasks in non-redundancy applications because more time
is required to conduct crossloads and synchronization.
An increase in the required watchdog time is also a result of the way programs are
executed in the event of a switchover. A program or programs can be executed a
second time after switchover. This action depends on when in the task or
program the switchover occurs and where in the task crossload and
synchronization occurs.
If a program is executed a second time, the length of time that is required for the
program scan is increased. However, the watchdog timer is not reset and
continues to countdown from the beginning of the task that the old primary
controller started. Therefore, the watchdog timer must be configured to account
for the potential of additional program scans.
Program 2 Program 3
Switchover
Task Crossload
Program 1 Program 2 Program 3
Crossload Crossload
Task Watchdog
In the event of a watchdog timeout, a major fault (type 6, code 1) results. If this
fault occurs after a switchover, the control system fails-to-safe or to the
configured hold state.
Program 2 Program 3
Switchover
Task
Crossload
Program 1 Program 2 Program 3
Crossload Crossload
Task Watchdog
The maximum_scan_time is the maximum scan time for the entire task when the
secondary controller is synchronized.
To set the initial task tuning of the ControlLogix 5570 controller, follow these
steps.
IMPORTANT This process works only when there is no Continuous task that is configured in the
Logix application.
1. Monitor the Max Scan Time for each task while the redundant chassis pair
is synchronized.
2. Set the Watchdog times for each task to three times the Max Scan Time.
3. To configure each Task Period, use the Logix 5000™ Task Monitor Tool.(1)
a. Adjust the Task periods of each so that the maximum scan time is less
than 80% of the task period rate.
b. Adjust the Task periods so that the Logix CPU % utilization is never
above 80%.
c. While performing these tests, the HMI and any other external systems
must be connected to the Logix controller.
Download the Project Download the project only to the primary controller. When the secondary
controller is synchronized, the system automatically crossloads the project to the
secondary controller.
IMPORTANT If the secondary chassis was qualified and becomes disqualified after you
download the project, verify that you have enabled the controller for
redundancy.
(1) See the PlantPAx® DCS Configuration and Implementation User Manual Manual, publication PROCES-UM100.
Store a Redundancy Project Use this procedure to store an updated project and firmware to the nonvolatile
to Nonvolatile Memory memory card of the controller.
IMPORTANT We recommend that you store the same project on the nonvolatile memory
cards of both controllers. By doing so, you can be assured that if a controller,
primary or secondary, loses the project from its internal memory, you can
load the most recent project back onto that controller.
If you store the same project on the nonvolatile memory cards of both
controllers, while the process is running, you must save the project on the
controllers while they are in the secondary controller state. To do so, you
save the project on the secondary controller, conduct a switchover, and save
the project on the new secondary controller. Even if you do not plan to use
the SD card, leave the card installed in the controller to collect diagnostic
information that you can provide to Rockwell Automation Technical
Support.
For more information, see the steps in Store a Project While the Controller is
in Program or Remote Program Mode on page 150 or Store a Project While a
System is Running on page 151.
1. Verify that the redundant chassis are synchronized. If they are not
synchronized, synchronize them.
2. To put the primary controller into Program or Remote Program mode, use
programming software or the mode switch.
3. In RSLinx Classic communication software, right-click the redundancy
module and choose Module Configuration to open the RMCT.
If you want to store your controller project in nonvolatile memory while your
redundant system is running, complete these steps.
2. In the RMCT, access the Configuration tab and set the Auto-
Configuration parameter to Never.
3. In the Synchronization tab, click Disqualify Secondary.
4. Go online with the secondary controller.
IMPORTANT Do not go online with the primary controller until you have completed
this procedure.
5. Open the Controller Properties dialog box and click the Nonvolatile
Memory tab.
6. To store the project in nonvolatile memory, click Load/Store then <--
Store.
7. In the RMCT, click the Synchronization tab.
8. Click Synchronize Secondary and wait for the system to synchronize.
9. Click Initiate Switchover.
Load a Project
If you must load a project from nonvolatile memory, you must first disqualify
your redundancy system. You then load the project from the nonvolatile memory
card to the primary controller, and resynchronize the redundant chassis once the
load is complete.
For details about loading a project from nonvolatile memory, see the Logix 5000
Controllers Nonvolatile Memory Card Programming Manual,
publication 1756-PM017.
Online Edits You can edit the redundant controller program while the system is online and
running. However, considerations specific to redundancy must be made with
considerations described in the Logix 5000 Controllers Quick Start,
publication 1756-QS001.
Beginning with redundancy system revision 19.052 or later, you can use the
Partial Import Online (PIO) feature available in the programming software.
Consider these points when using PIO with redundancy systems at revision
19.052 or later:
• If you select Import Logix Edits as Pending or Accept Program Edits
when executing a PIO, the primary controller treats the PIO feature as a
set of multiple test edits where, after the import is complete, you can
switch between testing the edits or not.
• We recommend that you do not use Finalize All Edits in Program when
you import edits. If you use this option, any failure due to the import
causes a failure on the new primary controller after a switchover.
• If edits exist in the primary controller due to a PIO, they are treated the
same as normal test edits regarding the ‘Retain Test Edits at Switchover’
selection and Redundancy System Update.
• If a PIO is in progress, the primary controller rejects any attempt to
qualify.
• If you attempt to initiate a PIO on a primary controller in the process of
qualifying the system, that PIO is rejected.
When the anomaly occurs and the PIO fails, you can see any of these
errors:
– Failed to import file 'c\...\xxx.L5x
Object already exists
Before you begin editing your redundant program while your system is running,
verify that the Retain Test Edits on Switchover setting meets your application
requirements.
IMPORTANT We recommend that you leave the Retain Test Edits on Switchover
setting at the default (that is, unchecked) to avoid faulting both
controllers when testing your edits.
If you enable the system to retain the test edits on a switchover (that is, you check
Retain Test Edits on Switchover), faults that result from the test edits can also
occur on the new primary controller after a switchover.
If you do not enable the system to retain the test edits on a switchover (that is,
you leave Retain Test Edits on Switchover unchecked), faults that result from the
test edits are not carried over to the new primary controller in the event of a
switchover.
Use this table to determine the Retain Test Edits on Switchover setting that suits
your application.
To change the Retain Test Edits on Switchover setting, click the Redundancy tab
in the Controller Properties then click Advanced.
When you assemble edits to your program while online, the original program
that existed before the changes were made is deleted. As a result, if the edits you
assemble cause a fault on the primary controller, the new primary controller also
faults after the switchover. Also, when you assemble edits in the primary
controller, the edits are also assembled in the secondary controller.
Before you assemble any edits to your program, test the edits to verify that faults
do not occur.
TIP Even if you have not enabled the Retain Test Edits on Switchover
property, faults can still occur on the primary and secondary controllers if
the edits are assembled.
The Retain Test Edits on Switchover property affects only edits that are
being tested. The Retain Test Edits on Switchover does not affect the
redundant controllers that are running assembled edits.
5. At the Accept the Pending Edits dialog box, click Yes.
IMPORTANT Do not change the Memory Usage settings for Tags and Logic unless
Rockwell Automation Technical Support instructs you to change the
settings.
Depending on your redundant application, you may need to change the memory
usage property for your redundant controller. The setting that you specify
impacts how the controller divides memory for tags and logic to be stored to the
buffer during a crossload to the secondary controller. Table 22 indicates when
you can consider changing the memory usage setting
.
IMPORTANT Do not set the Memory Usage slider to only Tags or Logic:
• Moving the slider to only Tags can block you from performing edits while online and OPC
communication can fail.
• If you move the slider to only Logic, you cannot create or edit any tags while online.
Topic Page
Controller Logging 159
Monitor System Status 161
Verify Date and Time Settings 163
Verify System Qualification 164
Check the EtherNet/IP Module Status 166
Check the ControlNet Module Status 168
This chapter describes some of the key tasks to complete to monitor and
maintain your redundancy system.
Controller Logging Beginning with redundancy system revision 19.052, you can use the controller
logging feature. This feature provides a way to detect and log changes. These
changes include programming software and controller mode switch interactions,
made to ControlLogix® 5560 and ControlLogix 5570 controllers, without
adding any auditing software.
• Detect changes and create logs entries that contain information about the
changes.
• Store the log entries to a CompactFlash (CF) card or Secure Digital (SD)
card for later review.
• Provide programmatic access to log entry counters to provide change
detection information remotely.
Controller Log
A controller log is the record of changes. The log is stored on the NVS memory of
the controller automatically. You can move the log to a CF card or SD card on an
as needed basis or automatically at predefined times. The NVS memory of the
controller and each external memory card type has a maximum number of entries
that they can store.
For more information on controller logging, see the Logix 5000 Controllers
Information and Status Programming Manual, publication 1756-PM015.
For more information, see the Logix 5000 Controllers Information and Status
Programming Manual, publication 1756-PM015.
Monitor System Status IMPORTANT When programming your redundancy system, program so your
redundancy system status is continually monitored and displayed on
your HMI device.
If your redundancy system becomes disqualified or a switchover occurs,
the change in status is not automatically annunciated. You must program
the system to communicate the change in status via your HMI or other
status-monitoring device.
For most redundant applications, you must program to obtain the status of the
system. Program to obtain system status when you do the following:
• Program HMI to display the system status
• Precondition logic to execute based on the system status
• Use the diagnostic information to troubleshoot the system
To obtain the status of your redundant system, use a Get System Value (GSV)
instruction in your program and plan for the tags you are writing the values to.
In the following example, the GSV instruction is used to obtain the chassis ID
(that is, the chassis A or B designation) of the chassis that is functioning as the
primary. The PhysicalChassisID value is stored in the PRIM_Chassis_ID_Now
tag. The PhysicalChassisID value that is retrieved matches the Chassis ID
indicated in the Controller Properties dialog box.
Ladder Logic
Structured Text
Chassis ID in Controller
Properties
Verify Date and Time Verify that the Redundancy Module Date and Time information matches the
Settings date and time of your system after you have configured and downloaded your
redundant system to the controller.
TIP Consider checking the Redundancy Module Date and Time as a part of
your regular maintenance procedures. Regular verification of the date
and time information keeps the event logs of the redundancy modules
accurate.
If the date and time are not correct, the redundant system event logs do not
match the date and time information for the rest of the system. Incorrect date and
time information complicates troubleshooting if an event or error occurs on your
redundant system.
2
Verify System Qualification After you have completed programming your redundant system and have
downloaded your program to the primary controller, check the system status to
verify that the system is qualified and synchronized.
TIP The system qualification process can take several minutes. After a
qualification command or a switchover, allow time for qualification to
complete before acting based on the qualification status.
You can view qualification status by using the status displays and indicators of the
secondary redundancy module and the primary and secondary ControlNet® and
EtherNet/IP™ communication modules.
This example shows status display messages and status indicators that can appear
differently depending on the qualification status of the redundant chassis. The
following are only two examples of status display message and indicator
combinations for both the qualified and disqualified states.
Qualified Redundant Chassis Disqualified Redundant Chassis
1756-L63
Secondary Chassis Secondary Chassis
1756-L63
1756-L63
To determine the qualification status of your system by using the RMCT, open
the RMCT and view the qualification status in the bottom-left corner of the tool.
Check the EtherNet/IP After you have programmed your redundant system and configured your
Module Status EtherNet/IP network, check two statistics specific to your EtherNet/IP modules.
These statistics include the CPU usage and the connections used.
To view the CPU usage and the number of connections that are used, complete
these steps.
1. In RSLinx® Classic software, open the Module Statistics for the EtherNet/
IP module.
2. Click the Connection Manager tab.
The CPU usage of the EtherNet/IP modules must be at 80%, or less. CPU usage
below 80% reserves enough CPU functionality for the EtherNet/IP module to
facilitate a switchover.
If the CPU usage is above 80%, the secondary chassis can fail to synchronize with
the primary chassis after a switchover occurs. In addition, unscheduled
communication can be slowed.
If you must reduce the CPU usage of your EtherNet/IP modules, consider
making the following changes:
• Increase the Requested Packet Interval (RPI) of your connections.
Increasing the RPI rate of a connection reduces the loading on the
associated communications modules
• Reduce the number of devices that are connected to your module.
For additional details about reducing the CPU utilization of your EtherNet/IP
modules, see EtherNet/IP Network Devices User Manual, publication
ENET-UM006.
If the connections of your EtherNet/IP modules that are used are near the limits
of the module, you can experience difficulty when attempting to go online with
the system. This difficulty arises because going online with a processor also
consumes a connection, if the attempts to go online are through the
communication module that is near the limit. You can also experience difficulty
when attempting to add modules to the system.
Check the ControlNet After you have programmed your redundant system and configured your
Module Status ControlNet network, check two statistics specific to your ControlNet modules.
These statistics include the CPU usage and the connections used.
To view the CPU usage and the number of connections that are used, complete
these steps.
1. In RSLinx Classic software, open the Module Statistics for the ControlNet
module.
The CPU usage of the ControlNet modules must be at 80%, or less. CPU usage
below 80% reserves enough CPU functionality for the ControlNet module to
facilitate a switchover.
If the CPU usage is above 80%, the secondary chassis can fail to synchronize with
the primary chassis after a switchover occurs. In addition, unscheduled
communication can be slowed.
If you must reduce the CPU usage of your ControlNet modules, consider making
the following changes:
• Increase the Network Update Time (NUT) of the ControlNet network.
• Increase the Requested Packet Interval (RPI) of your connections.
• Reduce the number of connections through the ControlNet modules.
• Reduce the number of messages that are used in the program.
If the connections of your ControlNet modules that are used are near the limits
of the module, you can experience difficulty when attempting to go online with
the system. This difficulty arises because going online with a processor also
consumes a connection. You can also experience difficulty when attempting to
add modules to the system.
Notes:
Topic Page
General Troubleshooting Tasks 171
Check the Module Status Indicators 172
Use Programming Software to View Errors 173
Use the RMCT for Synchronization Attempts and Status 176
Use the RMCT Event Log 178
Event Log Tab 187
System Event History 197
Keeper Status Causing Synchronize Failure 201
Partner Network Connection Lost 204
Redundancy Module Connection Lost 206
Redundancy Module Missing 207
Qualification Aborted Due to a Non-redundant Controller 208
Redundancy Module Status Indicators 209
General Troubleshooting When an error or other event occurs on the redundancy system, several tasks can
Tasks be executed to determine the cause. After an error or event, you can perform these
tasks:
Check the Module Status If an error or event occurs in the redundancy system, check the module status
Indicators indicators to determine which module is causing the error or event.
If any of the modules have status indicators that are steady or flashing red, then
examine that module status display and the RMCT or other software to
determine the cause.
CH2 CH1 OK
For more information about module status indicators, see Redundancy Module
Status Indicators on page 209.
Figure 50 - Module Status Displays for Chassis with ControlLogix 5560 and ControlLogix 5570
Controllers
ControlLogix® 5560 Controller and 1756-RM Module ControlLogix 5560 Controller and 1756-RM2 Module
ControlLogix 5570 Controller and 1756-RM Module ControlLogix 5570 Controller and 1756-RM2 Module
Use Programming Software To view redundancy status by using programming software, complete these steps.
to View Errors 1. Go online with the redundant controller.
Primary Controller
Secondary Controller
5. If controller fault details are needed, click the Major Faults and Minor
Faults tabs to view fault types and codes.
These fault bits are status bits that the controller sets. You can set these
fault bits for testing, but that is not the main purpose of these bits.
The fault codes that are listed and described in Table 26 are specific to redundant
controllers. For information about all controller major and minor fault codes, see
the Logix 5000 Controllers Major, Minor, and I/O Faults Programming Manual,
publication 1756-PM014.
Table 26 - Redundant Controller Major Fault Codes
Type Code Cause Recovery Method
12 32 A disqualified secondary controller was power cycled and no Verify that these conditions exist:
partner chassis or controller was found upon power-up.
• A partner chassis is connected.
• Power is applied to both redundant chassis.
• Partnered controllers have the same:
– Catalog number
– Slot number
– Firmware revision
12 33 An unpartnered controller has been identified in the new Use either of these methods:
primary chassis after a switchover.
• Remove the unpartnered controller and troubleshoot the
cause of the switchover.
• Add a partner controller to the secondary chassis,
troubleshoot the cause of the switchover, and synchronize
the system.
12 34 Before switchover, a mode switch mismatch was present. The Use either of these methods:
old primary controller was in Program mode and the mode
switch of the secondary partner was in the Run position. • Change the mode switches from Run mode to Program
mode and back to Run mode twice to clear the fault.
Instead of the switchover transitioning the new primary
controller to go to Run mode, the new primary controller Make sure that the mode switch positions for both
transitions to a faulted state after the switchover. controllers in a partnered set match.
• Use the programming software to go online with the
controllers. Then, clear the faults and change the mode
switch positions for both the controllers in the partnered
set to Run.
Use the RMCT for When troubleshooting your redundant system for anomalies with qualification
Synchronization Attempts and synchronization, check the Synchronization and Synchronization Status tabs
of the RMCT.
and Status
Recent Synchronization Attempts
The Synchronization tab provides a log of the last four synchronization attempts.
If a synchronization command was unsuccessful, the Recent Synchronization
Attempts log indicates a cause.
For more information about how to resolve the synchronization conflict, click
the attempt and view the Description in the lower box.
Depending on the type of synchronization failure, you may need to open the
Synchronization Status tabs for the primary and secondary redundancy modules.
• If there is a difference between major revisions of the controllers or
modules, the Compatibility column shows Incompatible, as shown in this
graphic.
Primary Chassis
Secondary Chassis
Primary Chassis
Secondary Chassis
Use the RMCT Event Log When troubleshooting your redundant system, access the Event Log to
determine the cause of an event, error, switchover, or major fault.
Primary Chassis
Secondary Chassis
2. If an event occurred, open the Event Log for both chassis (A and B).
3. Locate the Event line that shows the qualification code, start date, and
time of the event, in the A chassis event log.
This entry is the last time the redundancy module was working properly.
Multiple codes could be displayed if multiple errors occurred.
Additionally, if a secondary redundancy module is not present, then a code
can fail to b e seen at all. See Table 27 on page 181.
4. Then, locate the matching time entry in the B chassis event log. This entry
displays the disqualification code on the Event line.
Chassis A
Chassis B
5. Work back in time (up the lines of preceding events), to locate the point
that a switchover or disqualifying event occurred.
This is the end date and time of the event, and is indicated on the Event
line in the A chassis event log, with a disqualification code that the
secondary has been disqualified, and a corresponding disqualification code
in the B chassis event log. Again, if no secondary is present, the event log
can display no secondary disqualification codes at all. See Table 27 on
page 181.
Chassis A
Chassis B
6. To find the error that caused the disqualification, examine the range of
time in between the start of the event and the end of the event.
IMPORTANT This range of time can be large depending on how much time has passed
since the last disqualifying event.
End
Error
Start
End
Error
Start
TIP You can also use the Log Time column to identify a significant event. Scan
within a time range that corresponds to the time an event was reported or
annunciated.
In addition, you can also attempt to identify events by finding differences
between times logged. Such gaps in time often identify events that require
troubleshooting. When troubleshooting by identifying gaps in the time
entries, remember that gaps in months, days, or minutes can indicate a
significant change to the system.
Not all events that are logged are indicative of an anomaly that must be
corrected. For example, events that are classified as Minor Faults do not
warrant corrective behavior unless they occur just before a switchover,
major fault, or state change and can be identified as contributing to
successive events.
7. After you have located an event entry that is related to the anomaly you are
troubleshooting, double-click the event to view Extended Event
Information.
To export event logs with the RMCT version 8.3.1.0 or later, follow these steps.
1. Open the RMCT on the redundancy module in the primary chassis and
click the Event Log tab.
2. Click Export All.
3. Click OK.
4. Select the communication path to the partner redundancy module with
RSLinx Classic.
The Export Event Log configuration screen appears.
5. To change the file name or save location to something other than the
default, select the Browse button.
6. Click Export.
8. Click OK.
Export Diagnostics
You can also click Export Diagnostics if there is a module fault in the redundancy
module. Click Export Diagnostics to collect and save diagnostic data from the
redundancy module and its partner, if an unrecoverable firmware fault occurs. A
red ‘OK’ light on the front of the redundancy module indicates a nonrecoverable
fault, and a fault message scrolls across the marquee display. When you click
Export Diagnostics, information is recorded that Rockwell Automation
engineering can use to determine the cause of the fault.
Because diagnostic information is recorded for the redundancy module and its
redundancy partner, a communication path to the partner redundancy module is
also part of the process to obtain the diagnostics.
The Export Diagnostics dialog box appears and asks you to continue
specifying a communication path.
The Export Diagnostics dialog box appears and prompts you to specify a
location to save the export file.
The Export Diagnostic Complete dialog box appears once the export has
completed.
7. Click OK.
If you tried to use the event logs to troubleshoot your redundant system and are
unsuccessful, prepare to contact Rockwell Automation Technical Support by
exporting the event logs of both the primary and secondary redundancy
modules. The technical support representative who assists you uses those files to
help determine the cause of a switchover or other anomaly.
For more information about how to export the event logs, see Export Event Log
Data on page 191.
Controller Events
In other cases, the event description can indicate Program Fault Cleared, or a
similar description of a resolved anomaly. If state changes or switchovers do not
follow these types of events, then they are not indicative of an anomaly that
requires additional troubleshooting.
The Event Log tab provides a history of events that have occurred on the
redundant chassis.
IMPORTANT The events that are logged in this tab are not always indicative of an error.
Many of the events that are logged are informational only.
To determine if additional action or troubleshooting is required in response
to an event, see Table 29 on page 188.
The Event Log tab can be customized to view the log specific to only one chassis
or the event logs of both redundant chassis. You can alter your view of the event
logs by changing the Auto-Update and Partner Log parameters.
Check On to keep the log updating automatically. Check Close to view only the log of one redundancy module.
Event Classifications
Each event that is identified and logged is classified. You can use these
classifications to identify the severity of the event and determine if additional
action is required.
Event Classifications
Events that are logged in the Event Log tab can have additional information
available. To access additional information about an event, double-click an event
that is listed in the log.
Scroll to view
details of other
events.
The information that is listed in this table can be provided (depending on the
type of event) after you have accessed the Extended Information Definition
dialog box.
.
After you have viewed extended information about an event, you could need to
export event data. You can export data with either of these features:
• Export Selection
Export Selection
Use this feature to export event log data for single or multiple events that occur
on a primary or secondary redundancy module.
TIP If the redundancy modules are not available in RSLinx Classic software
after a fault, you must apply the recovery method that the module
indicates before attempting to export the Event Log data.
3. In the Auto-Update area, click Off to keep the log from updating.
5. Select one event or multiple events for which you want to export data. To
select multiple events, select a start event, press and hold SHIFT, and select
an end event.
TIP If you are sending the exported Event Log files to Rockwell Automation
Technical Support, you must use the CSV file type.
TIP If you are sending the exported Event Log files to Rockwell Automation
Technical Support, include the diagnostic data and extended
information.
If you include this data, Rockwell Automation Technical Support can
analyze module and system failures more effectively.
8. Click Export.
The event log is exported. The log can take a few minutes to export.
9. If you want to export the secondary redundancy module log for a complete
system view complete step 1…step 8.
IMPORTANT If you are exporting event data to provide to Rockwell Automation Technical
Support to troubleshoot an anomaly, you must obtain the event logs for
both the primary and secondary redundancy modules. Rockwell
Automation Technical Support needs the event logs to troubleshoot the
anomaly.
If you cannot access the event log for the secondary redundancy module,
export it from the partner event log via the primary redundancy module.
We recommend that you get the logs by choosing export all with the CSV
file type.
Keep in mind, though, that the view the primary redundancy module has of
the event log of the secondary redundancy module is typically limited. To
troubleshoot an anomaly with Rockwell Automation Technical Support, you
must obtain the event log of the secondary redundancy module from the
view of the module itself.
Export All
Use this feature to export all available event log data for events in both of the
redundancy modules of the redundant chassis pair automatically.
Complete these steps to export event log data for one event.
TIP If the redundancy modules are not available in RSLinx Classic software
after a fault, you must apply the recovery method that the module
indicates before attempting to export the Event Log data.
7. Click Export.
The event log is exported. The log can take a few minutes to export.
8. Click OK.
A .csv and a .dbg file is in the folder location specified. Make sure to
provide the .csv file to Rockwell Automation Technical Support when
troubleshooting an anomaly.
Clear a Fault
You can use the Clear Fault feature on the Event Log tab to clear major faults that
occur on a redundancy module.
With this feature, you can remotely restart the redundancy module without
physically removing and reinserting it from the chassis. The module restart clears
the fault.
IMPORTANT Export all event and diagnostic data from the module before you clear major
faults from the module. Clear Fault is active only when the redundancy
module is in a major faulted state.
Module faults are displayed on the Module Info tab. This example graphic shows
information for a module that has experienced a minor fault.
System Event History The System Event History tab is designed to give a user with limited knowledge
of ControlLogix Redundancy systems an event history.
The last 20 events are logged in the System Event History tab. There are 10
events from each redundancy module.
To edit the User Comment that is associated with a system event, complete these
steps.
Event Examples
This section contains System Event History records for typical system events.
The examples in this section are from Firmware Enhanced Redundancy Bundle
V20.056_kit1, RMCT version 8.2.1.0.
Table 30 - Manual Switchover
Event Class Basic Info Extended Info-A Extended Info-B
Switchover Commanded – –
Table 37 - Disqualification Due to Network Connection Lost between Primary and Secondary Chassis
Event Class Basic Info Extended Info-A Extended Info-B
(1)
Switchover Module Fault Chassis B - Slot No: xx Possible Causes:
1. Network Cable Removal(2)
2. Controller Program Fault
(1) xx = module slot number.
(2) This lost connection is not a network cable removal issue. The communication modules not being able to see each other over the network has caused the lost connection.
Keeper Status Causing To determine if a keeper status anomaly is causing a synchronization failure, you
Synchronize Failure can view the module status display of the ControlNet modules. You can also
check the keeper status by using RSNetWorx for ControlNet software.
TIP To avoid anomalies with the Keeper Status, always reset the ControlNet
module configuration of a module being used as a replacement before
inserting and connecting the module in a ControlNet network.
For more information about how to reset the ControlNet module
configuration, see Automatic Keeper Crossloads on page 88.
To check the status of keepers on the ControlNet network, open RSNetWorx for
ControlNet access the Keeper Status from the Network menu.
This example shows a Keeper Status dialog box where the ControlNet network is
composed of valid keepers and signatures.
Unconfigured Keeper
The following example shows the Keeper Status dialog box where a module has
an unconfigured status. Besides the status that is shown, the module status display
indicates Keeper: Unconfigured (node address changed).
This error results when the node address of the module has been changed. After
changing the node address, the module was used as a replacement and inserted
into the redundant chassis.
This example shows ControlNet modules in the redundant chassis that do not
have the same keeper signatures. With this anomaly, the ControlNet module
display indicates Keeper: Signature Mismatch.
This anomaly can result if a ControlNet module configured for the same node of
another network is used to replace a ControlNet module with the same node
address in the redundant chassis.
Partner Network If a partner network connection between a redundant chassis pair is lost, a state
Connection Lost change or switchover can occur. These state changes can result:
• Primary with qualified secondary changes to primary with disqualified
secondary
• Qualified secondary with primary to disqualified secondary with primary
To use the Event Log to determine if a lost partner network connection caused a
state change, complete these steps.
IMPORTANT This example shows a connection that is lost over a ControlNet network. The
same steps apply if the connection is lost over an EtherNet/IP™ network.
1. Open RSLinx Classic software and access the RMCT of the primary
redundancy module.
This chassis is the chassis that was previously the secondary but is now the
primary.
Primary Chassis
Secondary Chassis
2. Locate the last event that indicates successful qualification and status.
Primary Chassis
Event Log
A switchover is
initiated.
3. Open the Event Log for the secondary chassis because the cause of the
switchover is not apparent.
4. Use the time of the switchover event that is found in the primary chassis to
identify the corresponding event in the secondary chassis.
The corresponding events in the secondary chassis log indicate that the
network is not attached and that the SYS_FAIL_LActive backplane signal
is active. Both these events indicate an error in the connection of the
ControlNet module to the network.
5. Confirm the ControlNet connection error by browsing the network in
RSLinx Classic software.
Redundancy Module To determine if the connection between the redundancy modules caused a
Connection Lost switchover or state change, open the Event Log of the redundancy module that is
the primary.
The Event Log clearly indicates that one of the redundancy modules has been
disconnected. In addition, the dimmed secondary chassis log indicates that the
module is not connected.
To resolve this anomaly, check the intermodule cable that connects the
redundancy modules. Verify that it is properly connected and is not severed.
Redundancy Module To determine if a missing redundancy module caused a state change and
Missing switchover, access the Event Log of the chassis that is the primary chassis.
Dimmed secondary
chassis log indicates
issue with redundancy
module.
The redundancy module logs the Partner RM Screamed event just before it is
disconnected. Depending on the cause of the missing module, the Partner RM
Screamed event can fail to be logged before the module is lost.
You can also browse to the redundancy module in RSLinx Classic software to
determine if it is connected to the network. A red X over the redundancy module
indicates that RSLinx cannot communicate with the module.
To correct the missing module anomaly, first verify that the redundancy module
is correctly installed in the chassis and it is properly powered. Then check the
intermodule cable that connects the redundancy modules.
After you have verified that the module is installed and powered, you can need to
synchronize the chassis by using the synchronization commands in the
Synchronization tab. Use the synchronization commands if your Auto-
Synchronization parameter for the chassis is not set to Always.
Qualification Aborted Due If you place a controller that is not enabled for redundancy into the redundant
to a Non-redundant chassis, the qualification and synchronization fail. To determine if your
synchronization failure is due to a non-redundant controller, complete these
Controller steps.
Redundancy Module Status The redundancy modules have these diagnostic status indicators.
Indicators
1756-RM2 and 1756-RM2XT Status Indicators
Figure 59 - Redundancy Module Status Indicators for 1756-RM2 and 1756-RM2XT Modules
PR I M
CH2 CH1 OK
CH2 CH1 OK
OK Status Indicators
The CH1 and CH2 status indicators reveal the following module states.
Table 44 - CH1 and CH2 Status Indicators
Indicator State Description
Off One of these conditions exists:
• No power
• RM major fault
• NVS update
Steady green(1) Channel is operating as the active channel.
Steady red One of these conditions exists:
• No transceiver plugged in
• Faulted or failed transceiver detected
• Transceiver with incorrect or vendor ID detected
Intermittent red For 1 s, then off, indicates power-up.
Flashing red One of these conditions exists:
• Redundant channel error
• No cable connection
Intermittent green(1) On for 256 ms for each packet that is received, then off. Active operating channel.
(Channel that is used for data communication between the partner 1756-RM2
modules.)
Flashing green(1) Indicates that this channel is operating as the back-up channel and is ready to
become the active channel if the current active channel fails.
(1) Can be present for either CH1 or CH2, but not both simultaneously.
Status Indicators
PRI COM OK
PRI COM OK
OK Status Indicators
The Chassis State (PRI) status indicator identifies whether the chassis is primary.
The PRI status indicator on the primary redundancy module remains steady
green, and the PRI status indicator on the secondary redundancy module
remains off.
When the redundancy module experiences a fault, indication of that fault type is
presented in these methods:
• Event log
IMPORTANT This section describes a subset of module fault codes you can see in the
event log or Module Status Display.
If you see a fault code that is not included in this chapter, contact Rockwell
Automation for assistance in troubleshooting that fault.
The redundancy module logs the fault type in its event log in NVS memory. You
access the event log through the RMCT to troubleshoot the fault yourself or with
assistance from Rockwell Automation Technical Support for troubleshooting the
fault.
A character string scrolls across the Module Status Display to indicate the fault
type. The character string displays the fault type in either of these ways:
The fault code is a four-character alphanumeric string. Valid characters are 0…9
and A through Z, except S and O. The first character is always E. Each firmware
subsystem within the redundancy module is assigned a range of fault codes. Each
subsystem assigns fault codes within its range.
If you encounter one of these error codes, record the Exxx code and contact
Rockwell Automation Technical Support.
Recovery Messages
For certain faults, the module status display provides recovery instructions. Up to
four, four-character words are displayed.
Table 50 - Recover Messages
Recovery Instruction Code Description
RPLC MOD Replace the redundancy module only.
RSET RM2 or RSET MOD Reset the redundancy module only.
REMV MOD Remove the redundancy module only.
SEAT MOD Reinsert only the redundancy module into the chassis.
Notes:
Topic Page
Update the Configuration in Programming Software 220
Replace Local I/O Tags 222
Replace Aliases to Local I/O Tags 223
Remove Other Modules from the Controller Chassis 224
Add an Identical Chassis 225
Upgrade to Redundancy Firmware 225
Update the Controller Revision and Download the Project 225
Update the Configuration These steps provide an overview of the process that is required to update the
in Programming Software I/O Configuration tree in the programming software.
1. If you have I/O in the chassis with the controller, add a ControlLogix
communication module to the appropriate network because I/O modules
are not permitted in a redundant chassis.
You can now move the I/O modules to the new chassis in the I/O
Configuration tree.
2. Copy the I/O modules and paste them into the chassis of the newly added
communication module.
Replace Local I/O Tags If you have moved I/O modules out of the local controller chassis and into the
remote I/O chassis, complete these steps to find and replace the local I/O tags in
your program.
1. Open the routine where the local I/O tags must be updated.
2. Press CTRL+H to open the Replace in Routines dialog box.
The find/replace is completed and the results are indicated in the Search
Results tab.
Replace Aliases to Local I/O If your program uses alias tags for the I/O modules that you are moving,
Tags complete these steps to replace alias tags.
Remove Other Modules If modules other than those modules listed in Table 1 are in the controller chassis,
from the Controller Chassis you must remove them. You can use these modules in ControlLogix redundancy
systems. Not all components are compatible with all redundancy system
revisions. To make sure of component compatibility, see the release notes specific
to your redundancy system revision in the PCDC at:
http://www.rockwellautomation.com/global/support/pcdc.page.
Table 1 - Components Available for Use in a Redundant Chassis Pair
Module Type Cat. No. Available with Available with Available with Available with Available with
Redundancy System: Redundancy System: Redundancy System: Redundancy System: Redundancy System:
Revision 31.05x, Revision 24.05x, Revision 20.05x Revision 19.05x Revision 16.08x
Revision 32.05x Revision 30.05x
Revision 33.05x
Communication 1756-CN2(1) x x x x x
modules
1756-CN2R(1) x x x x x
1756-CN2RXT x x x x x
1756-EN2F x x x - -
1756-EN2T x x x x x
1756-EN2TR x x x x -
1756-EN2TP x - - - -
1756-EN2TXT x x x x x
Controllers 1756-L61, 1756-L62, - - x x x
1756-L63, 1756-L64
1756-L63XT - - x x x
1756-L65 - - x x -
1756-L71 x x x - -
1756-L72, 1756-L73, x x x x -
1756-L74, 1756-L75
1756-L73XT x x x x -
Redundancy 1756-RM - - x x x
modules
1756-RMXT - - x x x
1756-RM2 x x x x x
1756-RM2XT x x x x x
(1) You can use series B or later modules.
Add an Identical Chassis After you have configured your primary chassis with the modules that are listed
in Table 1, add an identical chassis that contains the same modules with the same
module-placement.
For more information about chassis configuration, see the section titled
Redundant Chassis on page 21.
Upgrade to Redundancy Once you have made the appropriate changes to your system configuration and
Firmware program, and have added the identical chassis, upgrade your system firmware.
For information about how to upgrade the redundant system firmware, see
Update Redundant Firmware on page 58.
Update the Controller After you upgrade the firmware, use programming software to access the
Revision and Download the controller properties and update the controller major revision to match the
redundancy firmware major revision you are using.
Project
Once you have updated the controller firmware revision and saved the changes,
download the updated program to the controller.
Notes:
Table of Redundancy Use this table of redundancy object attributes as a reference when programming
Object Attributes to obtain the status of your redundancy system.
Notes:
Topic Page
Chassis Configuration Checklist 231
Remote I/O Checklist 232
Redundancy Module Checklist 232
ControlLogix Controller Checklist 233
ControlNet Checklist 234
EtherNet/IP Module Checklist 235
Project and Programming Checklist 236
• ControlNet connections to the same ControlNet network as the redundant controller chassis, without bridging.
• EtherNet/IP connections to the same EtherNet/IP network as the redundant controller chassis, without bridging. If in the I/O tree of the redundancy controller, all
I/O and consumed tag connections must be multicast connections. The I/O tree of the redundancy controller can contain produced unicast tags that remote devices
consume.
• A DeviceNet® network that is connected through a 1756-DNB DeviceNet communication module in a remote, that is, non-redundant, chassis.
• A universal remote I/O or Data Highway Plus™ network that is connected by using a 1756-DHRIO module in a remote (non-redundant) chassis.
IMPORTANT The scan time is slightly extended when you downgrade a Series B redundancy module to a Series A module with a ControlLogix 5570
controller in the redundant chassis pair. In this case, raise the task watchdog limits by a factor of ~2x before downgrading. Thereafter, you can
retune the limits that are based on the updated scan time numbers.
ControlLogix 5560 controllers that are used with a combination of Series A and Series B redundancy modules in the redundant chassis pair
have the same performance a as if only Series A redundancy modules are used in the redundancy chassis pair. This result is regardless of the
primary or secondary redundancy state.
A fiber-optic cable connects the redundancy modules in the redundant chassis pair. The following are catalog numbers of fiber-optic cable you can order from
Rockwell Automation:
• 1756-RMC1 (1 m, 3.28 ft)
• 1756-RMC3 (3 m, 9.84 ft)
• 1756-RMC10 (10 m, 32.81 ft)
If necessary, you can make your own fiber-optic cable that is up to 4 km (13,123.36 ft) for the 1756-RM/B module or 10 km (32,808.40 ft) for the 1756-RM2 module.
ControlNet Checklist
Requirement
ControlNet Module
Identical ControlNet modules are placed in the same slot of both chassis of the redundant pair.
ControlNet modules are identical in redundancy firmware revision and in catalog number.
Only the 1756-CN2, 1756-CN2R, or 1756-CN2RXT ControlNet modules are used.
Partnered ControlNet modules both have identical keeper information as explained in the ControlNet Network Configuration User Manual, publication CNET-UM001.
Three connections of the ControlNet module are appropriately reserved for redundancy system use.
ControlNet Network
USB ports of communication modules in the redundant chassis are not used while the system is running (online).
At least four ControlNet nodes are used on the ControlNet network. That is, at least two ControlNet nodes are on the ControlNet network along with the two
ControlNet modules in the redundant chassis.
These requirements apply to at least one ControlNet node:
• It is not in the redundant chassis pair.
• It uses a node address lower than the ControlNet node addresses of modules in redundant chassis pair.
ControlNet module partners in the redundant chassis have the following:
• Node address switches set to the same address (for example, the switches of both modules are set to node address 13).
• Two consecutive node addresses reserved (for example, nodes 13 and 14) to accommodate a switchover. The primary ControlNet module can have an even or odd-
numbered node address.
The ControlNet network is scheduled by using techniques that are described in the ControlNet Network Configuration User Manual, publication CNET-UM001.(1)
Devices on other communication networks are bridged to the ControlNet network appropriately.
ControlNet HMI
A ControlNet network or a ControlNet-to-EtherNet/IP gateway is used to connect to HMI because your system requires that HMI be updated immediately after a
switchover.
• PanelView™ Standard terminal, PanelView 1000e, or 1400e terminal
For an unscheduled network, 4 HMI terminals per controller are used.
For a scheduled network, any number of terminals within the limits of the ControlNet network are used.
• PanelView Plus terminal, VersaView® industrial computer that runs a Windows CE operating system
RSLinx® Enterprise software, version 5.0 or later, is used.
Within each controller and communication module, five connections for each PanelView Plus or VersaView terminal are reserved.
• FactoryTalk® View SE software with RSLinx communication software, version 2.52 or later, RSView®32 software, FactoryTalk Linx software, version 5.0
The number of RSLinx servers that a controller uses is limited to 1…4 (maximum).
(1) Unscheduled ControlNet networks can be used, however, certain use considerations must be made. See Chapter 5, Configure the ControlNet Network on page 79.
Requirement
The Redundancy Module Date and Time has been set by using the RMCT (this in not required, but strongly recommended).
One project is created by using programming software and is downloaded to the primary controller.(1)
Redundancy is enabled within the Redundancy tab of the Controller Properties dialog box.
Time synchronization is not required for redundancy to function. If your application requires Time synchronization, then:
• Enable Time synchronization on the Date/Time tab of the Controller Properties dialog box.
• Select Time Sync and Motion on the Module Definition dialog box for the Ethernet module that is located in the local chassis.
Task configuration is either:
• One continuous task within the project.
or
• Multiple periodic tasks with only one task at the highest priority. Also, multiple tasks are structured at all different priorities and periods so that the fewest possible
separate tasks are used.
The redundant controller program does not contain:
• Event tasks.
• Inhibited tasks.
Programming specific to critical I/O that must be bumpless is placed in the highest-priority user task according to your task configuration.
If you use this task structure Then programming specific to bumpless I/O is in
One continuous task The continuous task.
One continuous task and one or more periodic tasks The highest-priority periodic task where only that one task is at the
highest priority.
Multiple periodic tasks The highest-priority periodic task where only that one task is at the
highest priority.
For ControlLogix 5560 controllers, the task watchdog is (2 * maximum_scan_time) + 150 ms when using ControlNet I/O and (2* maximum_scan_time) + 100 ms
when using Ethernet I/O, where maximum_scan_time is the maximum scan time for the entire task to complete when the redundant controllers are synchronized.
To calculate watchdog time for ControlLogix 5570 controllers, see Minimum Value for the Watchdog Time on page 148.
Scan time is minimized by using these techniques when possible:
• Unused tags are eliminated.
• Arrays and user-defined data types are used instead of individual tags.
• Redundancy data is synchronized at strategic points by using the Synchronize Data after Execution setting in the Program Properties dialog box.
• Programming is written as compactly and efficiently as possible.
• Programs are executed only when necessary.
• Data is grouped according to frequency of use.
• DINT tags are used instead of SINT or INT tags.
For produced/consumed data, the communication module in the remote chassis that holds the consuming controller uses the Comm Format: None.
Critical messages from a remote chassis to redundant chassis use cached connections.
Active tags on scan per controller are less than 10,000 tags/second.
(1) The project that is loaded on the primary controller is automatically crossloaded to the secondary controller when synchronization occurs.
Numerics configuration
1715 Redundant I/O systems 12, 14, 36 controller 112
EtherNet/IP modules 75
1756-CN2x modules 25 HMI 38
1756-EN2T remote I/O 36
sockets 72 RMCT
1756-EN2TR determine if needed 92
sockets 72 Configuration tab 98 - 100
1756-EN2Tx modules 25 connections
1756-RM communication 26
status indicators 172 controller 24
1756-RM and 1756-RMXT modules 24 continuous task
1756-RM2 46, 50 execution 117
recommended 117
1756-RM2/A
ControlFLASH 44, 59
ControlLogix 5570 123
crossload 122 controller 22
dual fiber ports 57 configure redundancy 112
status indicators 172, 209 connections 24
1756-RM2XT 46, 50 enable user program 100
event in Event Log 209
status indicators 209 save project 90
status 173
A troubleshoot
non-redundant 208
Array (File)/Shift instructions 130 use multiple 123
Auto-Synchronization 99 controller logging 159
ControlLogix 5560 233
ControlLogix 5570 233
B 1756-RM2/A 123
BOOTP/DHCP utility 75 memory usage slider 158
ControlNet
CPU usage 169
C keeper crossload 90
keeper status 88
calculate
module
task watchdog 148 check status 168
CH1 monitor CPU usage 169
status indicators 212 network update time 81
CH2 node requirements 30 - 32
status indicators 212 overview 30 - 33
chassis 44 produce/consume connections 79
designate 61 redundant media 33
ID 100 remote I/O 14
install 45 requirements 30 - 33
module placement 45 sample programs 167, 169
primary 15 schedule
secondary 15 existing network 87
chassis configuration list 231 new network 84
troubleshoot
CIP Sync technology 12, 69 keeper status 201
clearing a fault 196 lost connection 204
communication unscheduled 83
EtherNet/IP delay 28 conversion
module connections 26 non-redundant to redundant 62
modules 25 convert
communication module 44 nonredundant to redundant 219 - 225
unicast 19 CPU usage
components Ethernet/IP 65
overview 13
concise, program 128
crossload 46 execution
1756-RM2/A 122 continuous task 117
ControlNet keepers 90 periodic task 119
default 117 export data for a single event 191 - 193
estimate 121 export data for all events 194 - 195
redundancy object attributes 121 export diagnostics button 184
redundant system 15
scan time 121 export event log 191 - 195
extended event information 190
D
Data Highway Plus 35 F
date and time 100 FactoryTalk software 12
designate fiber-optic cable 56
primary chassis 61 redundancy channels 54
designation fiber-optic communication cable 44
chassis 61 firmware 58
conduct 15 revision 41
qualification after 62 signed and unsigned 13
DeviceNet 35 update 58 - 61
DSwNP firmware bundle 43
qualification status indicators 181 flash upgrade 58
DSwP
qualification status indicators 181
dual fiber ports H
1756-RM2/A 57 hardware
duplex setting 75 install 45
Human-Machine-Interface (HMI) 38 - 40
use over ControlNet 39
E use over EtherNet/IP 38
electrostatic discharge 47
enable
user program control 100
I
environmental considerations 43 I/O
EtherNet/IP 1715 Redundant I/O systems 12, 36
1715 Redundant I/O systems 12 in redundancy system revisions 14
configure module 75 multicast 232
delay 28 over EtherNet/IP network 12
duplex setting 75 placement 14, 36
IP address swapping 66 - 68 install
overview 34 hardware 44, 45
produce/consume connections 72 power supply 45
remote I/O 12, 14 primary chassis 45 - 52
requested packet interval 65 redundancy module 46
requirements 34 secondary chassis 52
set address 75 installation instructions 51
troubleshoot IP address
lost connection 204 BOOTP/DHCP utility 75
use of CIP Sync technology 69 consecutive 66
with HMI 38 plan 75
Ethernet/IP programming software 75
CPU usage 65 RSLinx communication software 75
Event Log set 75
controller event 209 swap 66
qualification events 63 swapping 66 - 68
RMCT 178 switches 75
Event Log tab 187 - 196
clearing a fault 196
export data for all events 194 - 195 K
export single event data 191 - 193 keeper
extended event information 190 crossloads 90
status 88
mismatch 203 O
module status display 201
RSNetWorx for ControlNet software 201 online edits 152 - 158
unconfigured 202 finalize 155
valid 202 reserve memory 157, 158
troubleshoot 201 retain edits 154
test edits 153
operations
L chassis designation 15
laser radiation ports 50 crossload 15
qualification 15
log redundancy system 15
Recent Synchronization Attempts 102 switchover 15
logic, scan-dependent 131 synchronization 15
optical ports 48
M
memory usage slider P
ControlLogix 5570 158 parallel redundancy protocol 77
mode switch Partial Import Online 152
REM 59 periodic task
Module Info tab 96 - 97
execution 119
module placement recommended 117
chassis 45 power supply 27, 44
module status display 164 install 45
monitor primary chassis 15
ControlNet designate 61
sample programs 167, 169 designation 61 - 63
motion installation 45 - 52
unsupported feature 13 produce/consume connections
MSG instruction 144 over ControlNet 79
multicast over EtherNet/IP 72
I/O 232 produced tags
unicast 72
program
N crossload
network 83 default 117
scan time 121
ControlNet
enable user control 100
monitor CPU usage 169 finalize test edits 155
overview 30 - 33
logic after switchover 141
Data Highway Plus 35 maintain data integrity 130 - 133
DeviceNet 34, 35
manage tags 124
EtherNet/IP 34
messages for redundancy commands 142 -
overview 28 - 29
146
keeper 88
monitor system status 161
keeper crossload 90
online edits 152 - 158
Remote I/O 34
optimize task execution 134 - 136
schedule
Partial Import Online 152
existing 87
reserve memory 157, 158
new 84
scan time
Universal Remote I/O 35
minimize 123 - 129
update time 81
synchronization
network update time 81
default 117
non-redundant controller 208 tags 124
non-redundant to redundant task type 117
conversion 62 test edits 153
nonredundant, convert from 219 - 225 use concise 128
programming software 75
project
save 90
PsDS
qualification status indicators 181
S synchronization 99
default 117
scan time description of 15
best performance 123 monitor after switchover 140
concise programming 128 Synchronization Status tab 104
crossload 121 Synchronization tab 101 - 104
efficient crossloads 124 - 127
minimize 123 - 129 attempts log 102
commands in 102
multiple controllers 123
system
number of programs 124
scan-dependent logic 131 qualification, system
synchronization 15
schedule system conversion 219
ControlNet 84 system overhead time slice 138
secondary chassis 15
System Update commands
designation 61 - 63
intallation 52 abort system lock 107
set IP address 75 initiate locked switchover 108
lock for update 106
SFP 211 System Update Lock Attempts 109
small form pluggable 56
System Update tab 105 - 110
transceiver 56
signed and unsigned commands 106 - 108
Locked Switchover Attempts 110
firmware 13
System Update Lock Attempts 109
SIL3
unsupported feature 13
single point of failure T
redundant fiber ports 12 tags
small form pluggable
manage 124
SFP 56
task 119
sockets
1756-EN2T 72 continuous, execution 117
optimize execution 134 - 136
1756-EN2TR 72
recommended 117
software
time and date 100
FactoryTalk Alarms and Events 41
FactoryTalk Batch 41 transceiver
FactoryTalk View Site Edition 41 SFP 56
optional 41 troubleshoot 171 - 209
programming software 75 check status indicators 172
RSLinx communication software 75 controller event 209
RSNetWorx for ControlNet 41 EtherNet/IP
RSNetWorx for EtherNet/IP 41 lost connection 204
RSView32 41 lost EtherNet/IP connection 204
status missing redundancy module 207
of qualification 63 qualification abort 208
via module status display 164 redundancy module
status indicators lost connection 206
missing 207
1756-RM 172 RMCT 178
1756-RM2/A 172, 209
synchronization
1756-RM2XT 209
keeper status 201
CH1 212
use
CH2 212
RSNetWorx for ControlNet software 201
use to troubleshoot 172
Studio 5000 Logix Designer 173
Studio 5000 Logix Designer 43
use to troubleshoot 173
subnet 66 U
switchover 15 unicast
description 16 communication module 19
example 108
locked attempts 110 produced tags 72
Universal Remote I/O 35
logic after 141
monitor synchronization after 140 unscheduled
test 166 ControlNet network 83
synchronization
automatic
unsupported feature
motion 13
SIL3 13
update
RMCT 96
system commands 106 - 108
upgrade
firmware 58 - 61
user program control 100
utilities
BOOTP/DHCP 75
V
version
RMCT 94
W
watchdog time 148, 236
workstation software 43
Notes:
Technical Support Center Find help with how-to videos, FAQs, chat, user forums, and product notification updates. rok.auto/support
Knowledgebase Access Knowledgebase articles. rok.auto/knowledgebase
Local Technical Support Phone Numbers Locate the telephone number for your country. rok.auto/phonesupport
Literature Library Find installation instructions, manuals, brochures, and technical data publications. rok.auto/literature
Product Compatibility and Download Center Download firmware, associated files (such as AOP, EDS, and DTM), and access product rok.auto/pcdc
(PCDC) release notes.
Documentation Feedback
Your comments help us serve your documentation needs better. If you have any suggestions on how to improve our
content, complete the form at rok.auto/docfeedback.
At the end of life, this equipment should be collected separately from any unsorted municipal waste.
Rockwell Automation maintains current product environmental compliance information on its website at rok.auto/pec.
Allen-Bradley, ControlFLASH, ControlFLASH Plus, ControlLogix, ControlLogix-XT, Control Tower, Data Highway Plus, expanding human possibility, FactoryTalk, FLEX I/O, Integrated Architecture,
Logix5000, PanelView, PhaseManager, PlantPAx, POINT I/O, PowerFlex, Rockwell Automation, RSLinx, RSNetWorx, RSView, Stratix, Studio 5000 Automation & Engineering Design Environment,
Studio 5000 Logix Designer, and VersaView are trademarks of Rockwell Automation, Inc.
CIP, CIP Sync, ControlNet, DeviceNet, and EtherNet/IP are trademarks of ODVA, Inc.
Trademarks not belonging to Rockwell Automation are property of their respective companies.
Rockwell Otomasyon Ticaret A.Ş. Kar Plaza İş Merkezi E Blok Kat:6 34752, İçerenköy, İstanbul, Tel: +90 (216) 5698400 EEE Yönetmeliğine Uygundur