1756-RM2 on DISQ: why the secondary won't sync, and what redundancy can't save you from

The call usually goes like this. "Redundancy is down, the secondary 1756-RM2 says DISQ, and we already swapped the fiber." Most of the time the fiber was never the problem. The module had been saying why it refused to sync the whole time, in plain English, in a tab nobody opened.

So here's the order I work through a pair that won't qualify: what the display means, where the real reason is written, and the short list of causes behind most of it. After that comes the part people usually learn the expensive way. A redundant pair protects you from hardware. Against your own program it does very little.

What the 1756-RM2 display is telling you

After power-up the secondary is supposed to go DISQ, then QFNG, then SYNC, and Rockwell puts that whole walk at one to three minutes. DISQ right after you power a chassis is just the starting point. Still sitting there well past that window, it's your problem.

Rockwell's note next to DISQ says to check the type and revision of the secondary partner module. Good first instinct, but not the whole list, and the display has a few more messages worth knowing:

Display	What it means	What I do
PRIM	This module is the primary	Nothing
QFNG	Secondary is qualifying	Wait, 1 to 3 minutes is normal
SYNC	Secondary is qualified and synchronized, ready to take over	Nothing, this is where you want to be
DISQ	Secondary is disqualified and cannot take over	Read the cause in RMCT (next sections)
????	Module is still resolving its state	Wait
!Cpt	Not every module in the chassis belongs to the same redundancy platform	Find the module that doesn't belong
ICPT	A test line on the backplane is asserted	Pull modules one at a time; if it stays, cycle chassis power or replace the chassis
Exxx	Major fault on the redundancy module, xxx is the error code	Write the code down, export the logs, then clear
Untrusted Certificate Error	The signed firmware file failed its check	Reflash from the correct redundancy bundle
Application Update Required	Module is running boot firmware only	Load the application firmware from your bundle
Link Down (CH1 or CH2)	That fiber channel lost contact: cable, attenuation, loose connector, or partner off or faulted	Check that one cable and its SFP
No SFP / SFP !Cpt / SFP Fail	Transceiver missing or loose / not supported by Rockwell / failed	Reseat or replace the SFP

 

Under the display sit three small LEDs: CH2, CH1 and OK. A flashing red OK means a firmware update in progress, a configuration problem, or a major fault you can clear remotely from RMCT. Steady red after the power-up self-test is a major shutdown fault. Cycle power, and if it comes back, the module is done.

Two paths between the chassis, and DISQ can come from either

This is the mistake I see most. People think of the fiber as "the redundancy link," so DISQ must mean fiber. A 1756-RM2 pair actually depends on two separate paths. The fiber between the redundancy modules carries the crossload. But to stay synchronized, the pair also checks that the partner EtherNet/IP modules can talk to each other over the plant network, and that every module pair across the two chassis is compatible.

Where each DISQ cause lives on a 1756-RM2 pair: the fiber link, the Ethernet path between partner communication modules, or a mismatch inside the chassis.

 

That's why "Partner Not on Same Link" has nothing to do with the fiber. RMCT describes it as the primary and secondary partners not being on the same network. Think switch port, VLAN, IP settings, an unplugged patch cord on the EN2TR. You can swap fiber cables all day and it won't change a thing. Which Ethernet modules are allowed in a redundant chassis in the first place, I went through in the 1756-EN2TR vs EN2T comparison.

The fiber side is simple by comparison. LC connectors, single-mode 8.5/125 µm, Rockwell's ready-made 1756-RMC1, RMC3 and RMC10 cables (1, 3 and 10 m), or your own run up to 10 km. Only one channel is active at a time and the other waits as a backup. When the active channel fails the module moves to the backup, the pair stays synchronized, and the controller scan sees a delay of 10 ms or less. Sync drops only when both channels are gone.

One cable works, then. A second one, routed along a different path, is cheap insurance. Match CH1 to CH1 and CH2 to CH2 while you're at it. Rockwell doesn't require it, but the first time you troubleshoot that link you'll be glad you did.

Read the reason in RMCT before you touch anything

The Redundancy Module Configuration Tool, RMCT, is where the 1756-RM2 writes down why it won't sync. On current installs it lives inside FactoryTalk Linx: find the module in the network browser, right-click, Device Configuration. On an older laptop it's RSLinx Classic, right-click, Configuration. If that menu item isn't there, the right RMCT version isn't installed, and version 7 or earlier doesn't support the RM2 at all. The FactoryTalk Linx RMCT 9.01.01 needs FactoryTalk Linx 6.21 or later and works with RM2 firmware 20.010 and up. Which Linx belongs on which PC is a topic of its own, covered in RSLinx Classic vs FactoryTalk Linx.

Then three tabs, in this order:

1.    Synchronization. The Recent Synchronization Attempts log keeps the last four tries. Abort means it failed; click that line and the cause plus a short description show up in the box below.

2.    Synchronization Status. One row per slot, with a Compatibility column. Every slot should read Full before you try again. A difference in the major or the minor revision between partners is already enough for Incompatible.

3.    System Event History. The last 20 events, ten from each module, written for the people who run the plant. The Event Log tab next to it goes much deeper, but Rockwell says itself that it's meant for their development engineers. I only open it to line up timestamps between chassis A and B when the cause still isn't clear.

One habit worth having: before you press Clear Fault on a faulted module, export the event log to CSV with extended information, once from the primary and once from the secondary itself. The primary only sees part of its partner’s log, and Rockwell support will ask for both.

The causes behind most DISQ, and where to look

The cause in the sync log is where you start. On the floor, the common ones come down to this:

Cause in RMCT	What it means	Where I look
Module Pair Incompatible	A pair in some slot doesn't match: catalog number, series or firmware	Synchronization Status tab, the slot that isn't Full
Partner Firmware Revision Not Compatible	Secondary firmware is older than the primary's	Update the secondary to match
Partner Not on Same Link	Partner Ethernet modules can't see each other on the network	Switch ports, VLAN, IP, cables on the Ethernet modules
Comm Disconnected	The cable between the redundancy modules is disconnected	Fiber, SFPs, CH1 and CH2 LEDs
Primary Not Time Synchronized / Secondary Not Time Synchronized	CIP Sync is on and one side isn't time synced yet	Time sync settings on the controllers and Ethernet modules, both chassis
Time Sync Configuration Error	A controller has time sync on but isn’t synced to a grandmaster, or the pair follows two different grandmasters	Same as above, plus the grandmaster itself
Non-redundant Compliant Module Exists	A module redundancy doesn't support sits in one of the chassis	Remove it; I/O modules don't belong in a redundant chassis at all
Module Configuration Error	One documented case: a controller that isn’t enabled for redundancy	Controller properties in Studio 5000
Unicast Not Supported	A unicast connection is configured in the redundant controller	Make it multicast, unless you run concurrent communication
Class 1 I/O Present with No IP-Swap	Class 1 connections on Ethernet partners that don't swap IP addresses	IP address swapping on the partner pair
Edit Session In Progress	Someone is editing online	Finish or cancel the edit
Keeper Mismatch	ControlNet partners have different keeper signatures	ControlNet systems only: update the keepers to match

 

Firmware: the newest 1756-RM2 file is not the right one

Each redundancy revision ships as a bundle, and the bundle names the exact firmware for the 1756-RM2. Rockwell lists compatible firmware per revision, so a file your bundle doesn’t list puts the pair outside what Rockwell supports. 20.031 is the one that catches people: it’s the newest RM2 file Rockwell offers, but it’s the firmware listed for the v35 bundles. A ControlLogix 5580 pair on 33.015 calls for 20.030.

Redundancy revision	1756-RM2 firmware	RMCT version
20.055_kit4	20.005	8.02.01
20.058_kit1 and 20.058_kit3	20.009	8.04.01
24.052_kit1	20.007	8.03.01
30.051_kit2	20.010	8.05.01
31.052_kit1	20.010	8.05.01
33.015 (ControlLogix 5580)	20.030	8.06.03
34.051_kit1 (ControlLogix 5570)	20.030	9.00.00
35.011 (5580) and 35.051 (5570)	20.031	9.01.00

 

For any kit that isn't in the table, read that kit's release notes before you flash anything. Two more traps. Going backward from 20.030 straight to 20.010 leaves the module on boot firmware; the way through is 20.030 to 20.009, then 20.010. And RMCT only syncs when the secondary is equal to or newer than the primary, while Rockwell’s install rule is identical modules, firmware included. Identical is what I leave a running pair at.

Time sync, the one hiding in plain sight

With CIP Sync enabled anywhere in the pair, both chassis have to actually be time synchronized before qualification goes through. Two setups fail every time. Time sync turned on in the primary controller but in no EtherNet/IP module in that chassis. Or a controller pair locked to two different grandmasters. Both look like a system that just won't qualify for no visible reason. Check the time sync setting on the controller and on every Ethernet module in both chassis, and set the two sides up the same way.

The QFNG and DISQ loop

Sometimes the display never settles: QFNG, DISQ, QFNG again, while the event log fills up. That's known behavior. Under some error conditions, usually configuration ones, the 1756-RM2 keeps trying to requalify the system forever. Set Auto-Synchronization to Never in RMCT, fix whatever the sync log names, then synchronize by hand from the Synchronization tab.

What a 1756-RM2 pair won't save you from

Redundancy is built for hardware. Rockwell's list of what triggers a switchover: loss of power, a major fault on the primary controller, a module removed, inserted or failed, an EtherNet/IP module that can't see any device on the network anymore, plus a switchover command from your program or from RMCT. The switchover itself can take as little as 20 ms.

Now look at what gets crossloaded to the secondary: tag values, forces, online edits, other project information, and major and minor faults. The secondary isn't a second opinion. It's a copy, running the same code on the same data, and after a switchover it starts the program from the beginning.

Say some scaling math writes a negative number into a TON preset. The timer throws a major fault, type 4, code 34, and the primary goes down. The secondary takes over with the same negative preset in the same tag. Same instruction, same fault. Two controllers, one bug.

A hardware failure is what switchover is built for. A fault that comes from the program travels with the crossloaded data and stops the secondary too.

 

How the usual faults play out on a redundant pair:

What happens	Fault	What the pair does
Power lost, module failed or pulled in the primary chassis	Hardware	Switchover, the secondary takes control
TON or RTO with .PRE or .ACC below zero	Major, type 4, code 34	Same data, same fault on the new primary
Array subscript out of range	Major, type 4, code 20	Same data, same fault
Logic raises a user-defined major fault	Major, type 4, code 990 to 999	It's in the program, so the copy raises it too
Watchdog timeout	Major, type 6, code 1	The watchdog isn't reset at switchover and a program can scan twice, so a tight watchdog faults the new primary
Divide by zero in a DIV	Minor, type 4, code 4	No switchover; an integer DIV returns Source A and both controllers carry on with the wrong number
A test edit faults the primary	Depends on one checkbox	Retain Test Edits on Switchover cleared: the new primary drops the test edits and keeps running. Checked: both fault
Edits finalized after a Partial Import Online fault the controller	Major	Both controllers fault, control is lost
Primary keyswitch in PROG or REM Program, secondary in RUN	Major, type 12, code 34	The new primary faults on switchover; keep both keyswitches in the same position

 

What helps is old-fashioned. For an instruction fault, type 4, the program's fault routine runs before the controller drops into fault mode. Clear the fault there and execution resumes with the next instruction, the faulted one doesn't run. Since the routine is part of the program, the secondary has it too. Better still, range-check the value before it ever reaches the preset.

File and shift instructions on controller-scoped data need a look as well. BSL, BSR, FFU, FAL, FBC, DDT and SRT can leave an array half shifted if a switchover lands in the middle of the instruction, and the new primary then shifts it again.

And the quiet one. A secondary that has sat on DISQ for a month protects nothing, and nobody notices until the day it's needed. Read the REDUNDANCY object with a GSV, attribute ChassisRedundancyState, and alarm on the HMI whenever the value isn't 16#2, primary with synchronized secondary. 16#3 is primary with a disqualified secondary, 16#4 is primary with no secondary at all.

Before you flash firmware or swap a module

On a new install, don't connect the fiber until both chassis are installed, flashed and configured. On a running system, this is the routine I stick to:

1.    RMCT, Configuration tab: set Auto-Synchronization to Never and apply.

2.    Synchronization tab: Disqualify Secondary. From here until the pair is back in SYNC, if the primary faults there's nothing to switch over to.

3.    Close RMCT before you flash the redundancy module. It helps avoid a timeout during the update.

4.    If you just powered the chassis, wait at least 45 seconds. The module is still running its power-up sequence and isn't ready for an update.

5.    Keep both controller keyswitches in the same position.

6.    When the update is done, set Auto-Synchronization back to your usual setting, synchronize, wait for SYNC on the display, then run Initiate Switchover from RMCT and check that the pair comes back synchronized.

Updating while the process keeps running is a procedure of its own, with tighter limits: it only works from revision 20.054 or later, only with ControlLogix 5570 controllers, and one major revision at a time.

Should a 1756-RM2 still go into a system?

Rockwell lists the 1756-RM2 as Active Mature with a replacement available. In January 2026 they also published a security advisory, CVE-2025-14027, that covers every RM2 and RM2XT firmware version. Malformed Class 3 messages, memory leaks and resource exhaustion can make the module unresponsive, in some cases with a major nonrecoverable fault, and recovery can take a restart of the module. The controller keeps running. No fixed firmware exists. Rockwell's answer is the 1756-RM3, and for those who can't move yet, their security best practices.

My take. On a running plant with RM2 pairs, a spare module on the shelf is the first thing I'd buy, as long as you also keep the bundle file you'd need to flash it to the exact revision your system runs. For a new system or a big upgrade, plan on the RM3. An RM2 only partners with another RM2 or RM2XT, so going to RM3 means both chassis at once, on a redundancy revision that supports it.

FAQ

Can a 1756-RM2 pair with a 1756-RM3?

No. It partners only with another RM2 or an RM2XT, and XT modules have to sit in an XT chassis. Moving to the RM3 means replacing the redundancy module in both chassis.

Does a 1756-RM2 need both fiber channels connected?

No. One channel is active and the second is a backup, so a single cable runs the pair. With two cables, losing one costs you a short scan hiccup, 10 ms at most, instead of synchronization.

How long should a 1756-RM2 take to get from DISQ to SYNC?

One to three minutes after power-up, passing through QFNG on the way. If it never gets past QFNG, or keeps cycling between QFNG and DISQ, read the cause in Recent Synchronization Attempts in RMCT.

Why does the secondary show DISQ when the fiber is fine?

Because most causes never touch the fiber. The usual suspects are a firmware revision that doesn't match the bundle, partner Ethernet modules that can't see each other, time sync, or a module that isn't allowed in a redundant chassis.

Will a 1756-RM2 pair ride through a program major fault?

Not when the fault comes from the logic itself. Major faults and tag data are crossloaded, so the secondary runs into the same fault with the same data after the switchover. A program fault routine and range checks are what protect you there.

Spares for a running 1756-RM2 system

If your pair is down to one healthy module, or you'd rather have the spare on the shelf before you need it, IQElectro stocks the 1756-RM2 and the conformal-coated 1756-RM2K, plus the 1756-EN2TR for the Ethernet side of the chassis. Still running original 1756-RM pairs? The 1756-RM is in stock too, just keep in mind it can't partner with an RM2. Every module comes with our 2-year warranty.