Resolving Siemens S7 OB80 System Fault in OB35 PID Loops

1. Problem Definition: OB80 Triggered by OB35 PID Execution

A SIMATIC S7-300/S7-400 CPU programmed with TIA Portal V13 SP1 Update 5 enters STOP (or remains running but logs an unacknowledged "System fault") the instant the operator attempts to switch a process PID controller to manual mode or pulse a reset input. The S7 diagnostic buffer records OB80, OB82, and OB122 as the error OBs being requested. The PID block is called inside OB35, the default 100 ms cyclic interrupt. While the loop runs untouched, control is normal. The fault only appears on the mode transition. This is a classic signature of a cyclic interrupt overrun, not a hardware failure.

The combination of OB80 + OB82 + OB122 is informative. OB80 is the time-error OB. OB82 is a diagnostic interrupt from a signal module (e.g. an SM 331/SM 332 analog module reporting wire break, channel fault, or overrange). OB122 is the programming-error OB fired when the program accesses an operand that does not exist at runtime (typically an out-of-range DB access triggered by corrupted data after the CPU was knocked into an inconsistent state). If only OB80 was present, the issue would be pure cycle-time. The presence of OB82 and OB122 indicates the OB80 STOP condition has cascaded into module diagnostics and pointer faults, and the operator must address all three layers.

2. Understanding OB80, OB82, and OB122 in S7

Reference: Siemens Industry Online Support entry "Organization blocks (OB) for SIMATIC S7-300/400" — the official OB list and priority class assignments.

When a CPU is configured with an error OB of a given number, the CPU calls that OB instead of going to STOP. If OB80 is loaded and configured in the CPU properties, the time error is "swallowed" and the CPU remains in RUN, which is exactly the symptom reported: the program keeps running but the diagnostic buffer shows "System fault". If OB80 is NOT loaded, the same overrun forces a STOP-to-RUN failure. The fact that the user has OB80 loaded means the CPU is surviving the time error, but the underlying overrun is still real and will eventually corrupt the PID state.

3. Root Cause: Cycle Time Overrun in OB35

OB35 is a cyclic interrupt OB with a configurable period (default 100 ms) and priority class 12. Every period, the CPU suspends OB1 and runs OB35. If OB35 has not finished executing by the time the next period begins, the CPU requests OB80 with OB80_FLT_ID = 16#0002 (OB request error: requested OB is still active). The most common triggers in a PID context are:

• PID block execution time > OB35 period. A standard CONT_C / PID_CP block in TIA V13 typically executes in 1-3 ms on an S7-315/317. Multiple PIDs back-to-back, or a heavy custom PID FB, can easily push total OB35 time over 100 ms.
• Mode-transition logic expands execution time. On a switch from "automatic" to "manual" or on a reset edge, the FB must (1) freeze the integral component, (2) initialize the manual value, (3) ramp the output to track PV, (4) update status bits, (5) clear internal flags. This extra work happens inside the same OB35 tick and can push execution over the configured period.
• OB35 priority is too low for the task. OB1, OB40 (hardware interrupt), and OB1-based FCs that share the same I/O can preempt OB35 indirectly by stealing CPU time slices. A periodic OB1 with high scan time (e.g. 80 ms) leaves only 20 ms of headroom for OB35.
• Process image update inside OB35. If the PID FB forces an I/O update with L PEW / T PAW direct-access calls, each access adds 0.5-1 ms. With 8-16 PIDs, this dominates.

4. Reading the S7 Diagnostic Buffer

1. In TIA Portal: Project tree → PLC → "Go online" → "Online & Diagnostics" → "Diagnostics buffer".
2. Click the most recent OB80 entry. The buffer shows the time, the OB number requested, the priority class, and a detailed event ID.
3. Open OB80 in online view. The temporary (TEMP) variables OB80_FLT_ID, OB80_ERROR_INFO, OB80_OB_NUMBER, and OB80_PRIORITY reveal the exact reason.

Sample diagnostic buffer entry you should look for:

Event 1 of 25:  Time error OB (OB80)  -  Priority class: 12
  OB requested: OB35
  FLT_ID: W#16#0002  -  OB request error
  ERROR_INFO: W#16#00C8  -  OB35 period (200 dec)
  Event 2 of 25:  Diagnostic interrupt OB (OB82)  -  Logical base: 256

FLT_ID 16#0002 confirms the cyclic OB is being requested again before the previous instance completed. ERROR_INFO high byte gives the configured period; low byte gives the priority. Use this to confirm that OB35 was the offender and that the period was the value you expected.

5. OB80 Local Variable Reference (FLT_ID Codes)

Reference: Siemens Industry Online Support — search "OB80_FLT_ID" for the official mapping table in the SIMATIC S7-300/400 system and standard functions manual.

6. Solution 1: Increase OB35 Cycle Time

1. Project tree → PLC → Properties → "Cyclic Interrupts".
2. Select the OB35 row.
3. Change "Cycle time (ms)" from 100 to a value 30-50% above the worst measured OB35 execution. For most PID-heavy projects, 200 ms is a safe starting point.
4. Optional: enable "Phase offset" (e.g. 50 ms) to desynchronize OB35 from the OB1 tick and reduce mutual preemption.
5. Recompile (Project → Compile all) and download to the CPU.

To measure the current worst-case OB35 time, add the following watch table entries under "Diagnostics / Profiling" or enable the "Cycle Time" measurement in the CPU web server. Alternatively, write a small FB that records OB35_BEGIN_TIME (SFC64 "TIME_TCK" at OB35 start) and computes delta at end. Persistent values > 80% of the period mean you are at risk.

7. Solution 2: Distribute PIDs Across Multiple Cyclic Interrupts

S7-300/400 CPUs provide 8 cyclic interrupt OBs (OB30 through OB38) with fixed priorities and independently configurable periods. The PCS7-recommended distribution strategy is to assign each PID to its own OB, with a small phase offset, so they run sequentially rather than all at once. Practical mapping on an S7-315-2 PN/DP with TIA V13 SP1:

Procedure in TIA Portal V13 SP1:

1. Project tree → PLC → Program blocks → "Add new block" → "Organization block" → OB36.
2. Set the period in the new OB's properties (PLC → Cyclic Interrupts).
3. Move one PID_FB call from OB35 into OB36. Configure the inputs to the same PV / SP / I/O addresses.
4. Repeat for as many PIDs as needed. Keep OB35 for the primary loop and a "hot spare" PID slot.
5. Compile, download, restart in RUN.

With the spread, total worst-case PID execution is still ~3 ms × N, but it is no longer accumulated into a single 100 ms bucket. This is the PCS7 "Reduction Ratio" pattern: each cyclic interrupt runs its own subset of blocks, none of them saturate, and OB80 stays quiet.

8. Solution 3: Reduce PID Execution Time

Code-level optimization that compounds with Solutions 1 and 2:

• Switch from direct I/O to process image. Replace L PEW 288 with symbolic access to the I-tag from the process image. Symbolic inputs are read from the IPI (input process image) at the start of OB1 and re-used by OB35 with zero extra cost. Symbolic I/O is enabled by default in TIA V13 SP1 when the symbol table is consistent.
• Disable the I/O update in OB35. If the PID block exposes a "Update_Process_Image" input, drive it FALSE except for the first OB35 tick after a mode change. This cuts the update from every tick to once per transition.
• Avoid DB accesses inside the PID loop body. Wrap DB calls in conditional code. IF ManualMode THEN ... END_IF; ensures manual logic only runs when needed.
• Profile with SFC87 "C_DIAG" or the Webserver cycle-time graph to identify which FB consumes the most time. Common offenders: FB186 (PID_CP auto-tuning), FB41 (CONT_C) with derivative action enabled, or any FC that calls a biquad filter per tick.

9. Solution 4: Address OB82 and OB122 Sources

OB82 fires when a diagnostic-capable I/O module (typically an SM 331 analog input or SM 332 analog output, e.g. 6ES7331-1KF02-0AB0) detects wire break, overrange, undervoltage, or a similar event. During an OB80 time error, the CPU may delay the I/O update long enough that the module's internal watchdog trips and reports the channel as faulty. Two-step fix:

1. Open the device view of the affected module, "Module parameters" → "Diagnostics" → confirm wire-break and overflow diagnostic are enabled for the channels in use.
2. In OB82, read OB82_MDL_DEFECT, OB82_IO_FLAG, and the structured local variable OB82_Z1 / Z2 / Z3 (channel status word) to identify the failing channel. Replace the wiring or add a 250 Ω shunt on a 4-wire RTD channel that is currently configured as 2-wire.

OB122 is a programming error: a direct access to a non-existent byte/word. After the OB80 time error leaves the PID in a transient state, a subsequent access (e.g. L DB100.DBW 200 when DB100 only has 100 bytes) fires OB122. In OB122, inspect OB122_SW_FLT (the type of error), OB122_BLK_TYPE, OB122_BLK_NUM, OB122_PRG_ADDR, and OB122_MEM_AREA to identify the access. In TIA V13, the structured "Program info" view jumps to the offending line. Wrap that access with a IF DB100.ActLength > 200 THEN ... END_IF; guard, or expand the DB to its maximum possible footprint.

10. PID Mode Switching Best Practices

The mode transition from "automatic" to "manual" is the moment where the FB carries the heaviest logic. To make it deterministic and OB80-safe:

1. Edge-trigger the mode change. Use a one-shot in OB1 (e.g. IF ManReq AND NOT ManReqOld THEN ManualMode := TRUE; END_IF; ManReqOld := ManReq;). The edge fires once, executes the manual init, and the next OB35 tick handles the steady-state.
2. Anti-windup before manual switch. Set the PID FB's "I_ITVAL_ON" (or the equivalent "I-ITVAL" on CONT_C) to FALSE before the mode flip. This freezes the integrator and prevents an integral bump on the next automatic switch-back.
3. Ramp the manual value. Instead of jumping the output to the manual setpoint, ramp it with the FB's built-in rate limiter. This smooths the transition and avoids a derivative spike on re-engagement.
4. Sequence the reset. Tie the reset input to an edge in OB1, not to a level. The level-held reset keeps the integrator dead and forces the FB to clear outputs every tick, expanding execution time.

11. Verification Procedure

1. After download, force the operator to switch the PID to manual in the HMI. Confirm the diagnostic buffer does not add a new OB80 entry.
2. Open a watch table in TIA V13: OB80_FLT_ID (read from a marker block in OB80's local data, copied at first call), OB80_CALLS (system-side counter in CPU system data), OB82_ENTRIES, OB122_ENTRIES. All three counters must remain flat across at least 50 mode transitions.
3. Run the worst-case scenario: toggle manual/auto every 200 ms for 10 minutes. OB80 must not fire.
4. Check the S7-300/400 web server: "Diagnostics" → "Cycle time" must show OB35 max < 70% of period. If max > 80%, distribute PIDs across more OBs.
5. Confirm the analog input quality byte in the IPI. The SM 331 channel status must show 0x00 (no fault) under all operating conditions.

12. TIA Portal V13 SP1 Configuration Notes

TIA V13 SP1 Update 5 is the last cumulative update for the V13 generation and supports both S7-300/400 (legacy) and S7-1200/1500 projects. A few items that often catch engineers upgrading from STEP 7 classic:

• Block compatibility. FB41 (CONT_C) imported from STEP 7 V5.5 is supported as-is. FB58 / FB186 (PID_CP) require the "PID Control Blocks" library under "Libraries → SIMATIC → Standard Library → PID Control". Confirm the library is installed in the TIA V13 SP1 setup (Options → Global libraries).
• Process image partition. TIA V13 SP1 introduces "Process image partitions" (PIP). Assign the PID I/O to PIP 1, automatically updated by OB35. This is the cleanest way to keep OB35's I/O deterministic.
• OB35 phase offset. Set this in the CPU properties, not inside the block. A 50 ms offset prevents OB35 from starting at the same instant as OB1's IPI update.
• Watch table v13 quirk. The online view of local data of OB80 was unstable in V13 SP1 prior to Update 4. If the watch table shows "Invalid handle", install Update 5 (which the user already has) and re-establish the online connection.
• Project size limit. The user's project is 5 MB. TIA V13 SP1 has a documented limit of 6 MB per project file; this is not the fault cause but is approaching the limit and explains why the upload was rejected on the source thread.

13. Field-Proven Quick Reference Table