S7-400H Redundancy Interrupt: 414-5H IF Module Diagnostics

1. Problem Statement

An SIMATIC S7-400H station built around a pair of CPU 414-5H controllers exhibits the following symptom during redundancy operation:

• As long as both CPUs remain in RUN, redundancy functions normally and the H system runs in dual-redundant mode without disturbance.
• When one CPU is forced to STOP (e.g. by an error, by STOP switch, or by service action), the remaining active CPU continues controlling the process.
• When the stopped CPU is requested to restart and to rejoin the H system, a short-duration interrupt on the process / I/O is observed.
• After the brief interrupt, both CPUs return to RUN-redundant operation and continue normally.

The core engineering question is: why is this brief interrupt visible at all, and what is the root cause in the redundant coupling path?

2. S7-400H Redundancy Architecture Overview

The S7-400H (High Availability) system provides a fully redundant automation cell based on:

• Two CPUs of the same type (e.g. 2x 6ES7414-5HM06-0AB0), physically installed in two separate racks (Rack 0 and Rack 1) that are electrically isolated but logically form one H-station.
• Two synchronization modules (IF1 and IF2) per CPU, plugged into the backplane slot reserved for the H-sync interface. The modules carry a fiber-optic transceiver each.
• Fiber-optic patch cables connecting CPU-A/IF1 to CPU-B/IF1, and CPU-A/IF2 to CPU-B/IF2. Two independent fibers are used to survive a single broken cable.
• One active role at any time: the Master executes the user program; the Reserve/Standby runs in lock-step, hot-synchronized through the fiber pair.

For the CPU 414-5H family, the relevant H-sync modules are typically:

For official module reference see the S7-400H automation system manual.

3. First-Response Diagnostic Procedure

When an S7-400H event is reported (a brief interrupt, an H state change, a CPU STOP, or a station fault), the first engineering action is to read the diagnostic buffer of both CPUs. The buffer is the authoritative timeline of what the firmware observed.

1. Open the project in STEP 7 V5.x or TIA Portal with the project file currently loaded in the CPUs.
2. Go online to CPU 1 (Rack 0): Online > Online & Diagnostics > Diagnostic Buffer.
3. Export the buffer as text (Save as text button). Do the same for CPU 2 (Rack 1).
4. Compare the two buffers with timestamps; align them. The master buffer and reserve buffer may differ, especially during the role transition.
5. For every entry, record: event ID, OB reference, and the associated module / diagnostic address.

Two outcomes are common for the reported symptom:

• Soft cause: an OB such as OB72, OB82, OB83, OB85, OB86 or OB87 was triggered because a module entered and left a fault state during the resync handshake. The process interrupt originates from the diagnostic-event-driven OBs the CPU executes.
• Hard cause: the IF (synchronization) modules themselves reported a transient loss of link. The diagnostic buffer will name the module and the diagnostic address of the affected IF module.

4. Root Cause in the Reported Case: IF Module Transient Fault at 8178 / 8179

The diagnostic buffer of the master CPU in Rack 1 revealed two suspect modules:

• IF module — diagnostic address 8178 (decimal) = 0x1FF2
• IF module — diagnostic address 8179 (decimal) = 0x1FF3

These are the system-side diagnostic addresses of the H synchronization modules, used by the CPU firmware to report insert/remove faults, communication errors on the redundant link, and link-quality degradations. In STEP 7 / TIA Portal they appear in the device list as IF (interface module for redundancy) and they are mapped to the H-sync slot of each CPU.

The pattern observed in the buffer is:

1. Master CPU is in RUN, Reserve CPU has been brought back into RUN.
2. During the resync handshake, one or both IF modules report a transient module fault (entry/leave within a few tens to hundreds of milliseconds).
3. The CPU logs the entry, schedules OB82, and—if a diagnostic OB is present—executes it; the cyclic user program is briefly interrupted at the OB boundary.
4. The IF module fault clears, the resync succeeds, and both CPUs are back in redundant RUN.

This is a classic module-fault coming-and-going pattern, and the correct interpretation is: the H system is healthy, but a hardware event on the sync modules or on the fiber is being correctly reported by the firmware.

5. Why OB72 Alone Is Not Enough

The user has correctly confirmed that OB72 is loaded. OB72 is the CPU redundancy error OB and is required for an S7-400H to start. It is invoked by the operating system on events such as loss of redundancy and stand-by-master role switch. It does not handle the module fault class.

To keep the diagnostic buffer informative and to control the interrupt length, the following diagnostic OBs should be present:

Since the IF modules are reported as module faults at address 8178/8179, the relevant OB is OB82. If OB82 is missing, the CPU would STOP on the very first module fault event, which is not what the user observes—so OB82 must be present. The remaining task is to ensure OB82 (and any other diagnostic OBs) contain code that records and clears the event quickly, instead of executing heavy logic.

6. Interpreting the Diagnostic Buffer Entries

When you open the buffer for the master CPU after a resync, you will see entries in the firmware-internal event ID range. For the S7-400H these cluster in the 0x73xx family. The most relevant ones for this symptom are:

7. Step-by-Step Troubleshooting Procedure

1. Capture the diagnostic buffer of both CPUs immediately after the next occurrence. Do not wait—ring buffers wrap.
2. Note the timestamp of the entry that names addresses 8178 and 8179. The delta between "coming" and "going" is the duration of the interrupt the process sees.
3. Filter for the 0x73xx range and identify whether the buffer says: sync module fault, sync link fault, or a generic module fault raised by the same physical module.
4. Read OB72 local data from the last call (in STEP 7: Online > Monitor/Modify > on the OB72 instance). OB72's start info contains the event that triggered redundancy loss, and helps to separate the role switch from the IF module event.
5. Read OB82 local data similarly. OB82 carries the logical base address and the diagnostic event flags. Confirm that 8178 / 8179 are flagged as the source of the module fault.
6. Inspect the IF module hardware:
   1. Power OFF both CPUs.
   2. Unplug the sync modules, inspect the pins, clean if necessary, reseat firmly.
   3. Inspect the fiber-optic connectors (POF / PCF / glass) for contamination, scratches, or excessive bend radius.
   4. Replace the fiber patch cable with a known-good one and re-test.
7. Check the LED status on the sync modules:

   LED	Color / State	Meaning
   ACTIVE	Green steady	Sync link active, data flowing
   FAULT	Red	Link error, cable error, or module fault
   LINK	Green flashing	Handshake in progress
   LINK	Off	No partner detected

8. Verify configuration in HW Config / Device Configuration: the two IF modules must have the same module order number, firmware version, and slot assignment in both racks.
9. Verify diagnostic address allocation: addresses 8178 and 8179 must be in the diagnostic address range used by the H system; they must not collide with PROFIBUS / PROFINET I/O.
10. Run a link self-test from STEP 7 / TIA Portal: Online > H Diagnostics > Synchronization > Self-test (where supported by the firmware). Watch for any cable or module error counter that rises during the test.

8. Common Root Causes of IF Module Transient Faults at 8178 / 8179

9. How to Read OB82 Local Data for This Fault

When the IF module raises a diagnostic event, the CPU calls OB82. The temporary local variables of OB82 contain the source of the event:

OB82_EV_CLASS    : BYTE  // 0x39 = coming, 0x38 = going
OB82_FLT_ID      : BYTE  // 0x0B for channel fault, 0x0C for module fault
OB82_PRIORITY    : BYTE  // 26 typical (process)
OB82_OB_NUMBR    : BYTE  // 82
OB82_RESERVED_1  : BYTE
OB82_IO_FLAG     : BYTE  // 0x54 = input, 0x55 = output, 0x56 = module
OB82_MDL_ADDR    : WORD  // logical base address of the module
OB82_MDL_DEFECT  : BOOL  // module defect flag
OB82_EXT_FAULT   : BOOL  // external (cable) fault
OB82_PNT_INFO    : BOOL  // point-to-point or DP/PN
OB82_EXT_VOLTAGE : BOOL  // missing external supply
OB82_FLD_CONNCTR : BOOL  // front connector missing
OB82_NO_CONFIG    : BOOL  // module not configured
OB82_CONFIG_ERR  : BOOL  // wrong configuration
OB82_MDL_TYPE    : BYTE  // 0x1F typical for H-sync module class
OB82_SUB_MDL_ERR : BOOL
OB82_COMM_FAULT  : BOOL
OB82_MDL_STOP    : BOOL
OB82_INT_FAULT   : BOOL

For the reported case, expect OB82_IO_FLAG = 0x56 and OB82_MDL_ADDR = 8178 (or 8179). If OB82_EXT_FAULT = TRUE, the cause is the fiber/cable. If OB82_MDL_DEFECT = TRUE, the cause is the module itself.

10. Recommended Code in OB72 and OB82

Keep the diagnostic OBs short. Their purpose is to acknowledge the event, capture context, and let the CPU continue. Long scan times inside these OBs extend the visible process interrupt.

// OB82 - I/O / module fault (simplified SCL)
// Local data of OB82 already in scope
IF OB82_EV_CLASS = B#16#39 THEN  // fault coming
    // Write to instance DB or HM tag for HMI
    "dbHDiag".IF1_event_coming := OB82_MDL_ADDR = 8178;
    "dbHDiag".IF2_event_coming := OB82_MDL_ADDR = 8179;
    "dbHDiag".TimestampComing := SFC1("TIMESTAMP");
    // Optional: SFB 52 "RDREC" to read DS0/DS1 from the module
    // for raw diagnostic bytes, then log to circular buffer.
    RETURN;
END_IF;

IF OB82_EV_CLASS = B#16#38 THEN  // fault going
    "dbHDiag".IF1_event_going := OB82_MDL_ADDR = 8178;
    "dbHDiag".IF2_event_going := OB82_MDL_ADDR = 8179;
    "dbHDiag".TimestampGoing := SFC1("TIMESTAMP");
    RETURN;
END_IF;

For OB72 (CPU redundancy error), at minimum:

// OB72 - CPU redundancy error
// Read OB72_OB_MEM (local data) to know the event:
//   EV_CLASS = 0x73 - redundancy loss
//   EV_CLASS = 0x74 - stand-by/stand-alone
"dbHRedundancy".LastOB72Event := OB72_RESERVED_1;
"dbHRedundancy".LastOB72Time := SFC1("TIMESTAMP");
// Force the new master to re-evaluate the role with
// SFC 90 "H_CTRL" if the project logic requires it.
// (Check TIA Portal / STEP 7 help for SFC 90 usage in your FW).

11. Verification and Commissioning Checklist

12. When to Consider Hardware Replacement

If, after the steps above, the diagnostic buffer continues to log OB82 events with going followed by coming multiple times per hour for the addresses 8178 / 8179, treat it as a deteriorating link rather than noise. Replace, in order:

1. Fiber-optic patch cables (both pairs).
2. Sync modules in the suspect rack.
3. The backplane connector of the sync slot if the module pins show wear.

Capture a new diagnostic buffer after each change to confirm the event is gone.

13. Cross-Reference: H-State Diagram and Resync

During the resync following a CPU restart, the S7-400H progresses through these H states (textual state machine, firmware-internal):

[STOP] --> [STARTUP] --> [SYNC_TEST]
        --> [LINK_TEST] --> [SYNC_UP] (data sync from master)
        --> [UPDATE] --> [RUN-redundant (Master / Reserve)]
        --> if any test fails --> [SOLO] (single) or [STOP]

The "interrupt" the user sees corresponds to the SYNC_TEST / LINK_TEST phase, where the firmware re-validates the IF modules and their fiber links. Any transient event recorded in that window will show up as an OB82 entry addressed to 8178/8179.

14. FAQ