Rockwell Automation 1756-RMxx ControlLogix Enhanced Redundancy System User Manual - Manual (Page 237)

Rockwell Automation Publication 1756-UM535D-EN-P - November 2012 237
Appendix
B
Event Log Descriptions
This table lists and explains some of the most-commonly experienced event
descriptions found in the Event Log of the RMCT. Use this table as a reference
when determining if an event on your system requires additional
troubleshooting.
Event Description Description
Autoqualification trigger Something happened that caused the system to try and synchronize again. Double-click the event to see what
happened.
Blank memories rule A check to choose a primary chassis if both chassis power up at the same time. Suppose that the controllers in one
chassis don't have projects while the controllers in the other chassis do have projects. In that case, the other chassis
becomes primary.
Chassis modules rule A check to choose a primary chassis if both chassis power up at the same time. Suppose that one chassis has more
modules than the other chassis. In that case, the chassis with the most modules gets the first chance to become primary.
It becomes primary as long as the other chassis isn't more able to control the system.
Chassis redundancy state changed to… The chassis changed to a different redundancy state.
• PwQS — Primary with qualified (synchronized) secondary partner
• QSwP — Qualified (synchronized) secondary with primary partner
• DSwP — Disqualified secondary with primary partner
• DSwNP — Disqualified secondary with no partner
• PwDS — Primary with disqualified secondary partner
• PwNS — Primary with no secondary partner
• PLU — Primary locked for update
• SLU — Secondary locked for update
Crossloading error A module is not able to get some information to its partner.
Disqualified secondaries rule A check to choose a primary chassis if both chassis power up at the same time. Suppose that the modules in one of the
chassis powered down in a disqualified secondary state. In that case, the other chassis becomes primary.
Failed modules rule A check to choose a primary chassis if both chassis power up at the same time. Suppose that a module in one of the
chassis is faulted but its partner module in the other chassis is not faulted. In that case, the other chassis becomes
primary.
Firmware error The redundancy module has an anomaly.
Improper mode or mode switch position A lock for update cannot be performed if the primary controller is faulted. A lock for update or locked switchover cannot
be performed if the mode switch on either controller is not in the REM position.
Incompatible application A lock for update cannot be performed if the project names or applications are not identical in the primary and
secondary chassis.
Initial secondary PTP time synchronization failure When PTP is enabled on the primary partner, the secondary partner must be PTP time synchronized as well or it will not
synchronize. The initial secondary PTP synchronization attempt may fail before the automatic retry is successful. In this
case, the event reports that initial failed attempt.
Invalid application A lock for update cannot be performed if test edits or SFC forces exist in the application.
Module insertion The 1756-RM now sees the module on the backplane. This means the module has either just powered up, just been put
into the chassis, or just finished resetting. Double click the event to see the slot number of the module.
Module rejected lock for update command from 1756-RM
module
A module (with a slot number specified in byte 0 of the extended status) rejected the lock-for-update command. See
events from that module to determine the cause.
Module removal The 1756-RM no longer sees a module on the backplane. This means that the module either experienced a
nonrecoverable fault, was removed from the chassis, or was reset. Double-click the event to see the slot number of the
module.