ControlLogix Redundancy with EN2TR

[slick_william]

Hello,

My associate and I are trying to sync up two ControlLogix racks (7-slot chassis) with identical modules. We are able to see the secondary rack increment the IP's of its two ethernet modules (+1 on each of the last octets as they should), however the secondary does not qualify and always shows "DISQ". We are unable to get these things to resolve even though we have done so on similar setups without the EN2TR being involved.

We have two identical ControlLogix 1756-L82e racks set up as follows:

(7 Slot Chassis)
Slot 0: 1756-L82e (CPU, v34.014)
Slot 1: 1756-RM2 (Redundancy module)
Slot 2: 1756-EN2T (Ethernet module, v 11.004)
Slot 3: 1756-EN2TR (Ethernet module, v 11.004)

We have both fiber pairs connected between the RM2 modules (two LC pairs, redundant). We have tried connected CAT5 cables between the EN2T's for example (EN2T in Rack A to EN2T in Rack B) and the same for the ENT2R's, always with similar results.

Previously, we were getting an error that the EN2TR was not set up for IP swapping capability. However we fixed this by setting the IP of the EN2TR to a different IP than the EN2T. We are now getting no errors, and all connections show Full Compatibility, but Disqualification.

Does anyone have any tips or tricks we can use to try to get these things sync'ed up? We have tried Time Sync, power cycling, disconnecting all other equipment, etc and are about out of ideas.

Any help is appreciated, thanks.

 

[Ken Roach]

Well, today I learned that the old rule that Redundancy bundles start with subrevision .050 doesn't apply anymore !

Do you have the Ethernet modules connected to actual switches so they can communicate with one another, at least the matched sets can ? Is there a specific reason for mixing 1756-EN2T and 1756-EN2TR modules ? Are you using a DLR ring on the 1756-EN2TR's ?

Usually the Redundancy Module Configuration Tool gives you the reason for failure to qualify. There's nothing in the event log suggesting a failure of some aspect of the qualification process ?

My guess is that if you don't have your switches installed and configured and you're just jumpering Ethernet modules to one another, that it's something to do with CIP Sync and the grandmaster clock selection. But *something* ought to tell you that.

 

[robertmee]

Well, today I learned that the old rule that Redundancy bundles start with subrevision .050 doesn't apply anymore !

Do you have the Ethernet modules connected to actual switches so they can communicate with one another, at least the matched sets can ? Is there a specific reason for mixing 1756-EN2T and 1756-EN2TR modules ? Are you using a DLR ring on the 1756-EN2TR's ?

Usually the Redundancy Module Configuration Tool gives you the reason for failure to qualify. There's nothing in the event log suggesting a failure of some aspect of the qualification process ?

My guess is that if you don't have your switches installed and configured and you're just jumpering Ethernet modules to one another, that it's something to do with CIP Sync and the grandmaster clock selection. But *something* ought to tell you that.

If it's a DLR, can only one EN2TR be set as supervisor and the Redundancy still work? Because if a rack failed, the other EN2TR would have to take over as supervisor. Would seem in this arrangement, you'd need a stratix to act as the supervisor and not either EN2TR. That's my logical thinking but ive never used redundancy, so maybe that's accomodated for in some other way?

 

[Contr_Conn]

First, you need to check RM2 firmware to make sure it matches revision listed in the reduncancy bundle.
Then, check Redundancy Module Configuration tool (RMCT) to make sure SYNC is set to Always.
RMCT can tell you what modules are preventing SYNC.
Pulling both Ethernet modules out of chassis is another trick that we use: just processor and RM2
Finally check Time Sync on the processor and both Ethernet modules, these must match.I usually leave them both ON, even I don’t need time sync. If RMCT is stuck at 80% then it’s a time sync setting.

 

[Contr_Conn]

Regarding post above about DLR supervisor - Both EN2TRs can have Supervisor enabled, only one will be the Active Supervisor, no need for another device to be the supervisor.
From my experience this is never a problem, compare to the Time Sync that is always prevents Sync.