Resolving S7-400H OB72 B#16#7341 Synchronization Error

1. Problem Overview

An S7-400H redundant PLC intermittently drops its standby CPU into STOP mode with the diagnostic entry "Synchronization error in user program due to waiting at different synchronization points," logged in organization block OB72 with event ID B#16#7341. Once the standby detects the error, the operating system forces a link-up / restart sequence; the redundant pair then continues operation. The fault typically re-occurs anywhere from several times per hour to once per day, making it difficult to correlate with a single user action, I/O event, or external disturbance.

This class of error is unique to the SIMATIC S7-400H high-availability platform, which is built on the principle of event-synchronous mirror operation: the standby CPU must execute the same user program at the same logical point in the cycle as the master, so that on a master failure the standby can take over without a program restart and without loss of state. Event B#16#7341 is the operating system's way of saying that invariant has been broken — the two CPUs reached a synchronization checkpoint at different logical positions in the program scan.

2. Decoding OB72 and Event ID B#16#7341

OB72 is the CPU-redundancy-error organization block. It is invoked when the S7-400H operating system detects a redundancy-related fault that requires user acknowledgement or programmatic response. OB72 is assigned priority class 26 by default — below the hardware-error OB family (OB80–OB87) and above the standard cyclic, time-of-day, and delay OBs in priority. On an S7-400H, OB72 is part of the redundancy kernel and is loaded automatically when an H-CPU is configured in STEP 7 / SIMATIC Manager.

The event ID is a 32-bit word with the layout xx xx 73 41 in hex (the first two bytes are the entry length, the second two bytes are the event identifier). The relevant fields decoded are:

The diagnostic buffer entry also carries the Mode field that identifies whether the CPU was MASTER or STANDBY at the moment of detection, the rack/slot of the affected CPU, and the most recent program-counter value. The Additional 1 word in particular points the engineer to the exact OB where the divergence was registered — typically OB1, OB35, or one of the hardware-interrupt OBs (OB40–OB47). Refer to the SIMATIC S7-400H System Manual for the full OB72 / event-ID encoding.

3. Mirror Operation and Synchronization Points

S7-400H achieves redundancy through event-synchronous mirror operation. The master and standby CPUs run identical firmware, identical STEP 7 user blocks, and identical configuration. At defined points in the cycle — the synchronization points — the standby inserts short pauses to wait for the master to reach the same logical position. The points are:

• End of OB1 scan (cyclic program)
• End of each time-of-day / cyclic interrupt OB (OB10–OB17, OB30–OB38, OB121/OB122 if used)
• End of each hardware-interrupt OB (OB40–OB47)
• Inside selected system SFCs that perform redundancy-relevant communication (e.g., SFC 90 / SFC 91 "H_CTRL", SFC 100–103 redundancy SFCs)
• Inside user calls to SFBs that participate in redundancy (e.g., SFB 14 / SFB 15 with the "RD_REC" / "WR_REC" distributed I/O redundancy pattern)

If the master CPU blocks at a synchronization point (for example, a wait inside a system call, a long-running SFC, or a debug breakpoint that was left enabled), the standby times out after a configurable interval (default 100 ms in classic H systems) and raises B#16#7341. The same event is raised if the standby reaches a sync point ahead of the master — for instance, because the master is in a higher-priority OB while the standby is in OB1. The S7-400H Redundancy Functions manual section 6.3 documents the exact list of sync points per CPU generation (CPU 412-3H / 414-4H / 416-3H / 417-4H / 410-5H).

4. Root Causes — Asymmetric Program Execution

B#16#7341 is almost always caused by asymmetric execution between the two CPUs. The most common culprits, in order of field frequency, are:

5. Diagnostic Buffer Analysis

Before changing code or hardware, extract the full diagnostic buffer (Diagnose → Buffer) from both CPUs for the 60 minutes surrounding the fault. Look for the pattern that immediately precedes the B#16#7341 entry. Common preceding patterns and what they indicate:

1. OB85 entry immediately before — I/O access error: the master handled it, the standby did not. Asymmetric I/O access; check for direct I/O reads of channels present on only one side, or for PEW / PAW in distributed I/O when the channel is on a redundant slave.
2. OB121/OB122 entry — programming error: the standby's OB121/OB122 differs from the master's. Verify OB121/OB122 are downloaded to both CPUs and contain identical code.
3. SFC 6 / RD_SINFO entry — a system call was skipped on one side.
4. Time-of-day entries jumping more than 100 ms — one CPU was busy at the OB1-end sync point, exceeding the default timeout. Increase the sync monitoring time via SFC 90 (H_CTRL) parameter MON_TIME (typical default 100 ms; can be raised to 200–500 ms in benign applications).
5. Hardware-interrupt OB entries only on the master — OB40–OB47 not loaded on the standby, or set to inactive.

Export the buffer to a CSV via the STEP 7 "Save As" function and align the two buffers in a spreadsheet. Tag the entries that occur on the master but not the standby within 100 ms — those are the candidates for asymmetric execution.

6. Hardware, Firmware, and Configuration Verification

Even with clean symmetric code, an S7-400H pair can produce B#16#7341 if the hardware baseline is not identical. Verify the following before opening the user program:

• CPU article numbers identical. Read the MLFB on the front of each CPU (for example, 6ES7 416-3ER05-0AB0). A 416-3FR05 and a 416-3ER05 are not interchangeable in an H pair — the firmware and feature set differ.
• Firmware versions identical down to the build number. STEP 7 → PLC → Operating Mode → Firmware Update displays the full version string (e.g., V5.4.8). A V5.4 and a V5.4.8 pair is not valid. Use Siemens S7-400H firmware compatibility lists to confirm.
• Memory card type and capacity identical. Flash cards of different capacity force the operating system to manage the user program at different offsets, which can subtly change the timing of large-block loads.
• Slot assignment identical. Both racks populated in the same order. A missing module on one side that is present on the other will produce scan-time differences large enough to trigger B#16#7341.
• Synchronization module firmware identical. The fiber-optic sync modules (6ES7 960-1AA04-0XA0 etc.) on the rear of the CPUs must match. Mismatched sync modules are a known root cause that mirrors as B#16#7341 even on an otherwise identical configuration.
• Project download state identical. Both CPUs must hold the same S7 program, with matching timestamps, matching block checksums, and matching HW Config. STEP 7 → Options → Compare Blocks → Online/Offline will reveal any drift.

7. EMC, Grounding, and Environmental Causes

Intermittent B#16#7341 with no software-side correlation is often a symptom of unequal electrical interference on the two CPU racks. The standby, having slightly different EMC exposure, can take microseconds longer to complete a memory access, throwing the sync point off. The SIMATIC S7-400 Automation System, Installation manual specifies the required grounding topology; key items to verify:

• Equipotential bonding between the two rack ground bars, conductor cross-section ≥ 16 mm², length < 1 m where possible.
• 24 V supply return (M) bonded to PE at a single point, not at the supply and at the load.
• Fiber-optic sync cables routed separately from power cables, minimum 200 mm parallel clearance.
• Shielded PROFIBUS / PROFINET cables with 360° bonding at the entry plate, not pigtails.
• Surge protection on any field cable that runs outside the cabinet.
• No ground loops between the H-pair cabinet and adjacent cabinets supplied from different mains phases.

A field-proven EMC smoke test: temporarily install a small ferrite (Würth 74270097 or equivalent) on each PROFIBUS drop at the CP, and re-run for 24 h. If the B#16#7341 rate drops, the EMC path is identified and a permanent fix (re-routing, additional shielding, or filter installation) is required.

8. Step-by-Step Resolution Procedure

Use the following ordered procedure to resolve a recurring B#16#7341. Each step lists what to verify and the recommended action.

1. Capture the fault context. From both CPUs, save the diagnostic buffer, the stack of the OB that was executing at the moment of the fault (OB1 / OB35 / OB40 etc.), and the project SHA / block checksums. Export the buffer to CSV.
2. Compare the two configurations. STEP 7 → Options → Compare Project → Online/Offline for both CPUs. Any "different" entry is suspect. Pay particular attention to the OB properties (priority, phase offset, active flag), HW Config of both CPUs, and the CP slots.
3. Match firmware, hardware, and memory. Update both CPUs to the same firmware (use the same .upd file on the same day). Replace mismatched sync modules. Replace mismatched flash cards. Re-download the project to both CPUs.
4. Audit the user program for asymmetry. In SIMATIC Manager, enable Block Consistency Check. Review every SFC/SFB call for H-suitability; in particular, verify that all SFC 90 / SFC 91 / SFC 100–103 calls and all SFB 12 / SFB 13 / SFB 14 / SFB 15 calls are present in the same call context on both sides. Remove conditional code that depends on first-scan-only flags or on tags that can have different initial values.
5. Audit interrupt OBs. Confirm OB10–OB17, OB30–OB38, and OB40–OB47 are loaded on both CPUs and have identical Active properties and identical phase offsets in HW Config.
6. Audit fail-safe blocks (if used). Confirm F-library version identical on both CPUs. F-sign-of-life, F-monitoring time, and F-runtime group parameters must match. Use the F-Configuration Check tool in S7 F-Configuration Pack to compare.
7. Raise sync monitoring time only after code audit is clean. If the process tolerates the longer failover, call SFC 90 "H_CTRL" with MON_TIME := W#16#0138 (500 ms in the S7-400H example block) to give the standby more head-room. This is a workaround, not a fix.
8. EMC and grounding pass. Walk the cabinet, verify the points in Section 7, measure the ground-loop resistance between the two rack ground bars (should be < 0.1 Ω). Add ferrite / shield / re-route as required.
9. Clean link-up and observe. Force a full warm restart, verify the link-up LEDs (INTF, EXTFLT, BUSF1/BUSF2, IFM1/IFM2) all green on both CPUs, and observe for at least 72 h before declaring the issue resolved.

9. Verification and Long-Term Monitoring

After applying the corrective action, instrument the system to catch any recurrence before it becomes a process event:

• Diagnostic-buffer archive — configure WinCC / PCS 7 to archive the S7 diagnostic buffer to a SQL or CSV store every 5 minutes. Compare weekly.
• Tag the event in STEP 7. In OB72, write a marker (e.g., DB99.DBX0.0 := TRUE) the first time OB72 is entered, and reset on restart. Surface this tag in HMI as an alarm. This guarantees a B#16#7341 is never invisible.
• Cross-CPU timestamp. Use SFC 1 "READ_CLK" in OB1 on both CPUs and archive both values; drift > 1 ms sustained indicates a sync-load imbalance that will eventually trip B#16#7341.
• Configuration drift check. Schedule a monthly "PLC → Compare Project" job in STEP 7 to confirm the online configuration still matches the engineering baseline. A drift here is the most common cause of a fault that "came back" months after the original fix.

10. Frequently Asked Questions