Resolving S7-400H CPU 414-5 OB Cycle Overload and 16#38B3 Errors

Problem Description

On a SIMATIC S7-400H station built around a CPU 414-5 H PN/DP (typical order number 6ES7414-5HM06-0AB0, firmware V6.x with PCS 7 V8.x/V9.0 SP1), the operator station running WinCC raises the alarm "Net time consumption of all OBs Exceed Max Limit". Simultaneously, the WinCC trend shows all analog outputs falling to zero, although every CPU in the H pair, every IM, and every I/O module reports RUN / OK / No fault in the diagnostic buffer. The alarm is repeatable and tracks a cyclical pattern at the configured OB35 scan rate (default 100 ms).

The accompanying CPU diagnostic buffer fills with sequential entries of Event ID 16#38B3, all classed as "External error, Outgoing event" with priority 25 and calling OB85 (Program Execution Error OB). The buffer offset field (Z1) shows 2942, and the access-address field increments by one byte at a time, e.g. 0011h, 0012h, 0013h … always on process image partition 0 (PIP 0), always for the output (P) area, always "byte access".

Affected Hardware, Firmware and Software

The same fault pattern is also reported on CPU 417-5 H (6ES7417-5HT06-0AB0) when a project over-allocates one OB. See the Siemens CPU_RT PCS7 V9.0 SP1 prevention-of-overload manual for the underlying performance model.

Diagnostic Event Analysis: Event ID 16#38B3

Event ID 16#38B3 is defined by the S7-400 operating system as "I/O access error when updating the process image". The seven-byte Coding field in the diagnostic buffer carries:

Because PIP 0 is the default process-image partition updated automatically at every OB1 scan start, a stream of 16#38B3 entries on PIP 0 with consecutive byte offsets indicates that the cyclic interrupt OB35 is consuming more CPU time than its 100 ms period. When OB35 overruns, the operating system cannot refresh PIP 0 for that cycle and flags every byte of the missed output area. Subsequent cycles catch up, but the analog-output process image is reset to zero between catch-ups, which is exactly what WinCC observes as "all analog outputs going to zero".

Root Cause: OB Cycle Overload

Three structural factors almost always combine to produce this fault:

1. Single-OB code allocation. The whole CFC chart collection is loaded into one runtime group on OB35. OB35 default period is 100 ms, configurable from 1 ms to 60 000 ms via HW Config → CPU properties → Cyclic Interrupts.
2. Scan time > period. Measured OB35 runtime has grown past 100 ms because chart count, block count, or I/O count has increased (post-commissioning plant extensions, additional loops). The @CPU_RT trend will show a saw-tooth pattern with peaks over 100 ms.
3. Time-error OB80 and Program-error OB85 not loaded. Without an OB80 the CPU goes to STOP at the first 2× cycle-time violation. Without OB85, the same for the I/O access error. Loading the OBs keeps the CPU in RUN but the alarm is re-raised every cycle — which is the desired "visible alarm" behaviour of the plant.

On an H system the calculation is further distorted: the H-link synchronization, the redundant I/O update, and the master/standby role swap each consume measurable time that is not visible inside @CPU_RT. Expect an additional 5–15 ms overhead that must be subtracted from the OB budget before sizing code distribution.

S7-400H Cyclic Interrupt OB Architecture (OB30 – OB38)

The recommended distribution model is to run PID controllers at the loop's natural process period, not at the default 100 ms. A temperature loop does not need 100 ms; a flow loop does not need 10 ms. Right-sizing each group leaves 30–50 % idle time as headroom for H-sync and transient peaks.

Time Error OB (OB80) and Program Error OB (OB85) Behaviour

The operating system calls OB80 whenever one of the following occurs (per the STEP 7 / TIA Portal S7-1200 time-error OB reference, which applies the same principle on S7-400H):

• The cyclic program exceeds the configured maximum cycle time (default 5 s for OB1, 2× the OB35 period if OB80 is loaded).
• OB80 itself is still executing when called a second time (nested overrun).
• The configured minimum cycle time cannot be honoured because OB35 ran past its end.

The operating system calls OB85 when an I/O access error is detected — for example, when the process image cannot be updated because the CPU is still inside a long-running OB. Event ID 16#38B3 is the diagnostic buffer trace of that OB85 invocation.

Solution: Distribute Program Across Multiple OBs

Execute the changes offline, then download to both CPUs of the H pair while the plant is in a safe state. Mark each step as you complete it.

Step 1 — Quantify the overload

1. Open WinCC Explorer and load the online trend @CPU_RT.
2. Select chart axis 1 = OB35 current runtime; axis 2 = OB35 maximum runtime.
3. Record the steady-state peak. If the peak is > 80 % of the 100 ms period, redistribution is mandatory.
4. Export the trend to CSV for the change-log.

Step 2 — Profile the CFC chart runtimes

Right-click the OB35 runtime group in the CFC editor and choose Run Sequence → Measure. A second window opens showing each chart's measured runtime in milliseconds. Sort descending. The top 5–8 charts typically consume 60–80 % of OB35's budget.

Step 3 — Create new runtime groups

1. In the CFC plan view, right-click Charts → Insert Runtime Group.
2. Create groups for OB33 (500 ms), OB34 (200 ms), and OB36 (50 ms). Leave OB35 on 100 ms.
3. Drag the slow charts (trending, batch flags, alarm accumulation) into the new OB33 group.
4. Drag pure housekeeping and slow diagnostics into OB34.
5. Keep the PID loops in OB35, and any high-speed safety functions in OB36.

Step 4 — Verify configuration

Confirm the HW Config → CPU → Cyclic Interrupts tab matches the new group assignments and that the period of each OB is greater than the maximum chart-runtime sum for that group, plus 20 % headroom.

Step 5 — Load and observe

Download to the standby CPU first, wait for redundancy sync, then switch roles and download the second CPU. Open @CPU_RT and confirm the new peak runtimes are below 80 % of period. The WinCC alarm should clear within two OB periods.

Using the CFC Runtime Group Editor

The Runtime Group Editor is the only sanctioned tool for moving code between cyclic OBs in PCS 7. Manual edits with the LAD/FBD/ST editor break the CFC chart's run-sequence and the documentation. The editor provides:

• Group Properties dialog — assigns the group to OB30–OB38, sets install state, watch-dog time.
• Sequence tab — drag-and-drop re-order of charts within the group.
• Reduction tab — selective chart reduction during plant commissioning.
• Display → Run Sequence — the runtime chart produced during Step 2 above.

Watch-dog time on every runtime group must be set to 2 × the OB period. If you set the watch-dog too short, OB80 will fire unnecessarily; too long, and the alarm you want to see is delayed.

CPU_RT Monitoring and PCS 7 Performance Tools

The @CPU_RT WinCC online trend view is the standard PCS 7 diagnostic for OB runtime. The relevant fields are:

For a deeper analysis use the PCS 7 maintenance station (Maintenance Workstation) which exposes CPU_RT@Maintenance archives and the Process Diagnostics view. The Siemens CPU_RT PCS7 V9.0 SP1 prevention-of-overload document shows how to derive the long-term load profile and which percent thresholds trigger a maintenance message.

Inline Diagram — OB35 Overrun Cascade

Verification and Acceptance Test

1. Restart the WinCC alarm logging; confirm Net time consumption of all OBs Exceed Max Limit does not reappear for at least one full plant-shift.
2. Open the CPU diagnostic buffer and filter Event IDs 16#38B3 and 16#4301. Both counters should be 0 (or only legacy entries pre-fix).
3. Force a role swap on the H pair and repeat the checks; H-sync overhead must not push any group over its period.
4. Trend every analog output that was previously zero. Confirm a continuous trace without dropouts.
5. Archive the new @CPU_RT CSV for the FAT/SAT report.

Preventive Best Practices

• Right-size loop periods. Default every PID loop to its physical process period, not to 100 ms. Use PCS 7 Advanced Process Library (APL) block CTRL_PID sample-time parameter for this.
• Reserve 30–50 % headroom. OB35 should never exceed 50 ms steady-state if the period is 100 ms. H-sync costs ~5 ms, leaving 45 ms for code.
• Cap OB36 and OB37 use. 50 ms and 20 ms OBs should hold only safety-relevant, deterministic blocks. Avoid large CFC charts there.
• Trend OB80CNT and OB85CNT. Add both to the maintenance alarm log so any future overload surfaces within minutes, not at the next plant trip.
• Document the @CPU_RT baseline. Export the trend at SAT and store the CSV in the project archive. Future modifications compare against this baseline.
• Never load application code in OB80 or OB85. They are alarm OBs, not execution OBs. Adding code there makes the overload worse.
• Use the PCS 7 Change Log (CHG_LOG) to record every OB period change. Operators reviewing alarm history need a clean audit trail.

Edge Cases and Field-Proven Caveats

• Watch-dog time mismatch. If the CFC group watch-dog time is left at the default (150 % of OB period) while the OB period is reduced to 50 ms, OB80 fires on a normal transient. Either re-compute the watch-dog or leave the period unchanged.
• S7-400 to S7-400H port. When migrating a single CPU 414-3 to a CPU 414-5 H pair, allow an extra 10 ms in OB35 budget for the H-link. New H systems have a slightly higher baseline than single-CPU projects.
• Firmware V6 to V7 migration. Some PCS 7 V9.0 SP1 installations running on legacy V6 firmware show a temporary OB35 spike during firmware update — schedule the update during a planned shutdown, not during production.
• CFC chart reduction. The Reduction tab in the Runtime Group Editor can be used during commissioning to temporarily skip non-essential charts; never leave a chart in "reduced" state on a running plant.
• PCS 7 OS server redundancy. If only one OS server shows the alarm, the cause is the WinCC archive cycle, not the CPU. Verify by trending @CPU_RT on both servers.

FAQ