Resolving S7-414-4H Link Up Cancel: H-System Firmware Sync

Problem Overview

An S7-400H redundant controller built around two CPU 414-4H modules (Siemens order code 6ES7 414-4HJ04-0AB0) stops establishing redundancy after a planned or unplanned CPU replacement. The HW Config diagnostic shows the event "Link Up Cancel" on the standby CPU, the redundancy link LEDs behave abnormally, and only one CPU ever reaches RUN. The second CPU stays in STOP, remains in solo RUN, or oscillates between STOP and RUN. The system was operating in full redundant mode before either a plant trip or a CPU swap introduced a different firmware version on the partner CPU.

The fault is reproducible without any field wiring changes: pulling and re-inserting a CPU with the same order number but different firmware is sufficient to break link-up. The root cause is the S7-400H link-up contract: both CPUs must share an identical MLFB, identical firmware version, identical memory-card capacity, and identical program image before the redundancy link will close.

Affected Hardware and Order Numbers

The issue is specific to the high-availability (H) CPUs in the S7-400 family. Verify the exact order number on the front flap of each CPU before proceeding. The article uses the following catalog identifiers as the reference configuration.

Reference the official product page at SIMATIC S7-400 CPU 414-4H manual collection for the full list of allowed accessories and current firmware release notes.

Root Cause Analysis

The "Link Up Cancel" condition is generated by the S7-400H system firmware when one of the link-up handshake checks fails. The handshake runs every time both CPUs complete their startup and try to enter redundant operation. The master CPU broadcasts a redundancy descriptor over the fiber-optic sync link that includes:

• Firmware signature (release, version, hot-fix level)
• Hardware MLFB and sub-version (ES index)
• Configured work-memory size
• Hardware configuration CRC
• User program CRC
• Memory-card capacity and type

If the standby CPU returns any mismatch in the descriptors, the master aborts the link-up with the diagnostic entry "Link Up Cancel" and refuses to release the standby into RUN. The standby then either remains in STOP or attempts solo RUN if it has been configured as the boot master.

The most common triggering mismatch in the field is a firmware difference between the two CPUs. Typical scenarios reported in operational plants:

1. A spare CPU from store was issued to replace a failed unit; the spare is on firmware V4.0.12 while the running unit was V4.0.7.
2. Both CPUs were updated separately at different times using a firmware update tool, leaving one at V4.5.2 and the other at V4.5.3.
3. The hardware configuration in HW Config was downloaded at a level (e.g., V4.5) that did not exactly match the firmware currently resident on either CPU.
4. A plant trip triggered a warm restart in which one CPU came up faster and detected a partner that was still booting; the partial handshake was recorded as "Link Up Cancel" even though firmware was identical.

In each case, the only way to clear the condition permanently is to make the two CPUs truly identical at the firmware, hardware-config, and program-image levels.

Understanding the "Link Up Cancel" Diagnostic

The "Link Up Cancel" entry is written into the diagnostic buffer of the standby CPU. The event is identified by a W#16#73xx class ID; the exact sub-event reveals the cancel reason. Common sub-events observed in 414-4H systems:

Always read the diagnostic buffer of both CPUs (not only the standby) and compare event timestamps. The buffer survives a power cycle and is the most reliable record of why a link-up was refused. On the 414-4H the diagnostic buffer can be read with STEP 7 V5.x under PLC → Diagnostic/Setting → Diagnostic Buffer, or in TIA Portal under Online & Diagnostics → Diagnostic buffer. See the official description of the CPU 414-4H diagnostic system in the S7-400 CPU 414-4H operating instructions.

Diagnostic Buffer Interpretation Around a Plant Trip

When the original incident includes a plant trip, the buffer typically shows a sequence similar to the example below. Timestamps are illustrative; the order, not the exact seconds, is what matters.

If your buffer shows a different cancel reason (e.g., 73E0 partner missing, 73E4 sync error), the firmware-swap procedure below will not help; instead investigate the fiber-optic link, sync-module seating, and sync-module version.

Prerequisites for Recovery

Before you start the recovery procedure, gather the following items.

• STEP 7 V5.5 SP4 or later, or TIA Portal V13 SP1 or later with the S7-400H HSP. The S7-400H option pack is required for redundant hardware configuration.
• Ethernet programming cable or PROFIBUS programming cable. The 414-4H integrated PROFINET interface (X1) is the fastest path.
• Latest firmware file for the 414-4H, downloaded as a .upd file. The current release for the V4.5 line of 6ES7 414-4HJ04-0AB0 is V4.5.4 (or the latest available version listed on Siemens Product Support entry Firmware update for S7-400 CPUs).
• Backup of the current STEP 7 project (S7 file or TIA Portal project archive).
• Same order number of CPU available for both racks. If you only have one spare, plan a two-stage recovery.
• Access to the operator panel or HMI to monitor MSTR / LINK / RUN / STOP LED transitions.

Step-by-Step Recovery Procedure

The procedure brings both CPUs to a known identical state in five phases. Allow 60-90 minutes for the full sequence, including the firmware write and the download of the project.

Phase 1 — Stabilize and Document the Current State

1. Switch the H system to solo RUN on the master CPU so the process stays running: in STEP 7 V5.x use PLC → Operating Mode → Switch Master/Standby, then power down or STOP the defective partner. In TIA Portal use Online & Diagnostics → Functions → Switch H-System.
2. Read and save the diagnostic buffer of both CPUs.
3. Read and save the current firmware version of both CPUs. In STEP 7: PLC → Operating Mode → Firmware Version.
4. Read and save the current user program from both CPUs: PLC → Upload Station to PG. Compare the two uploads with a file diff tool. Any mismatch is a candidate root cause on top of the firmware difference.

Phase 2 — Bring Both CPUs to the Same Firmware

1. Decide on a target firmware. Use the latest released version for your order number, e.g. V4.5.4 for the 6ES7 414-4HJ04-0AB0. Download the firmware from Siemens Product Support entry 6741018.
2. Set the standby CPU to STOP. Do not yet touch the master.
3. Open HW Config in STEP 7 (or the device view in TIA Portal), select the standby CPU, and run PLC → Operating Mode → Firmware Update (in STEP 7) or Online & Diagnostics → Functions → Firmware Update (in TIA Portal).
4. Browse to the downloaded .upd file and click Run Update. The CPU restarts automatically when the update completes. This step takes 5-10 minutes for a 414-4H.
5. Verify the new firmware version is reported correctly.
6. Switch the H system: promote the freshly updated CPU to master (Switch H-System), then STOP the other CPU and repeat steps 2-5 on it.

Phase 3 — Reload the Hardware Configuration

1. Open the STEP 7 project and verify that the CPU selected in HW Config is exactly the target order number and the highest available firmware index for that order number.
2. Compile the hardware configuration (Station → Save and Compile). Resolve any version-mismatch warnings before proceeding.
3. Download the hardware configuration to both CPUs: select each CPU in turn and use PLC → Download. STEP 7 will warn if the firmware on the target does not match the configuration; resolve the warning by selecting the firmware that matches the actual CPU.

Phase 4 — Reload the User Program Identically

1. Use the menu PLC → Download User Program to Memory Card. This option writes a consistent image to the memory card (flash) that is then available to the CPU at startup. If you do not have a memory card and only use RAM, use PLC → Download instead, and run it on both CPUs.
2. Confirm that the download completed without error on both CPUs.
3. Upload the program from both CPUs a second time and compare. They must be byte-identical.

Phase 5 — Re-Establish the Redundancy Link

1. Make sure both CPUs are in STOP.
2. Insert the sync-module fiber cables (or reseat them firmly) between rack 0 and rack 1.
3. Switch CPU rack 0 to RUN. Observe the LINK LED on both sync modules; it must transition from flashing to solid green within 10-30 seconds.
4. Switch CPU rack 1 to RUN. The standby CPU goes through its link-up handshake. The diagnostic buffer of both CPUs should now record the event 73E5 (standby ready for switchover) rather than a cancel event.
5. Verify in HW Config online: Redundancy → H-System Status must report Redundant, not Solo.

Verification and Commissioning Checks

After the procedure the H system must pass the following checks before the plant is released.

S7-400H Synchronization Architecture

The 414-4H implements redundancy at the controller level. Each CPU runs its own copy of the user program on its own data image. A fiber-optic redundancy link between the two CPUs continuously copies the process image, the timer/counter states, and the data-block values from the master to the standby. On a master STOP, the standby is already up-to-date and can take over the process output without a glitch.

Two physical interfaces are involved:

• Sync module interface (X5/X6 on CPU 414-4H): dedicated to the redundancy link. Connects to a sync module (e.g., 6ES7 960-1AA04-0XA0) on each side via LC duplex fiber. Operates at 100 Mbps internally; no external device should be connected.
• PROFINET interface (X1): used for the I/O on PROFINET, for HMI, and for programming. Both CPUs are normally on the same PROFINET ring or network and are addressable separately (e.g., 192.168.0.10 for rack 0 and 192.168.0.11 for rack 1).
• PROFIBUS DP interface (X2): optional, for PROFIBUS I/O or DP master/slave communication.

The link-up handshake performs the following checks in order, and stops at the first mismatch:

1. Both CPUs report the same MLFB and ES index.
2. Both CPUs report the same firmware signature (release, version, patch level).
3. Both CPUs have a memory card of the same capacity.
4. Both CPUs have the same hardware configuration CRC.
5. Both CPUs have the same user program CRC.

Any one of these failing is enough to cause the "Link Up Cancel" event with a corresponding 73Ex entry.

Related CP Module Considerations (CP 443-1 IT and CP 443-5)

Plants that pair the 414-4H with a CP 443-1 IT (for Ethernet / IT protocols) or a CP 443-5 Extended (for PROFIBUS) sometimes see the Link Up Cancel condition masquerade as a CP fault. The chain looks like this:

1. Firmware mismatch between the two CPUs causes link-up to be cancelled.
2. The standby CPU drops the CP module from its hardware configuration because the H-system state did not reach REDUNDANT.
3. The CP module generates an EXTF (external fault) diagnostic event, often with the message "CP not ready for operation" or "PROFIBUS master lost".
4. Maintenance is dispatched to check the CP and the bus, neither of which is the actual fault.

Before debugging the CP module, confirm that the H system itself is reporting REDUNDANT. If it reports SOLO, the CP fault is a consequence of the redundancy problem, not an independent fault. For the CP itself, see the diagnostics manual at SIMATIC NET CP 443-1 IT manual and the CP 443-5 Extended entry on the same portal.

Preventive Maintenance

• Store spare CPUs on the production firmware. Label the carton with the firmware version (e.g., V4.5.4). Update spares whenever a planned firmware upgrade is performed on the running pair.
• Avoid mixing firmware across a hot swap. If a CPU fails and a spare is on a different firmware, downgrade the spare to match the running unit (or upgrade the running unit and spare together). Do not put a higher-firmware spare into a lower-firmware pair.
• Use MMC cards of identical capacity. Siemens explicitly documents this as a requirement for H-system redundancy.
• Re-download after every plant trip. Some operators clear the buffer but not the program; clear both and re-download the project to both CPUs from the engineering station.
• Document the firmware baseline. Keep a single line in the plant asset register: "414-4H firmware = V4.5.4, both racks, both MMCs". Review the line annually.
• Plan firmware updates carefully. Always update the standby first, switch over, then update the (now former) master. See the firmware update procedure in SIMATIC S7-400H Fault-Tolerant Systems manual.

When the Procedure Does Not Resolve It

If after Phase 5 the standby still does not link up, the firmware parity is confirmed but the diagnostic buffer still shows a cancel reason, then escalate along the following path:

1. Check the fiber-optic link. Verify the sync module version on both racks is the same (e.g., both 6ES7 960-1AA04-0XA0). A V3 sync module on one side and a V4 on the other will refuse to link.
2. Measure the optical power budget. A fiber run that is on the edge of its budget may link intermittently and fail to handshake after a restart.
3. Replace the sync module on the standby side with a known-good spare, one rack at a time.
4. Replace the fiber cable with a known-good cable.
5. Open a support request with Siemens Technical Support and attach both diagnostic buffers and the STEP 7 project archive. Reference entry S7-400 CPU 414-4H manual in the ticket.