S7-300/1200 Cycle Time Exceeded: Root Cause and Resolution

Overview: What Happens When an S7 CPU Reports a Cycle Time Exceeded Fault

A Siemens S7-300, S7-400, S7-1200, or S7-1500 CPU monitors the execution time of the main cyclic program (OB 1) against a configurable maximum cycle monitoring time. If OB 1 does not complete within that window, the CPU calls the time-error organization block (OB 80 on S7-300/400, OB 80 on S7-1200/1500) and, if OB 80 is not loaded, the CPU transitions to STOP with the diagnostic buffer entry "Cycle time exceeded". On S7-300/400, the diagnostic event is also written as a CPU LED pattern (SF on, BF depending on the fault) and is recoverable only by warm restart, cold restart, or power cycle after the cause is removed.

The fault is non-fatal in code terms: the user program did not crash, it simply ran too long. The CPU's job is to protect the process from being controlled by a PLC that cannot keep up with its own scan, so it shuts down cleanly. The engineering task is to determine why the scan blew past its budget and to restructure the program so that OB 1 fits inside the configured monitoring time.

How the Cycle Watchdog Works on S7-300, S7-400, and S7-1200

The OB 1 cycle is supervised by the operating system. According to the Siemens Support entry 109975922 on STOP caused by cycle time exceeded, the maximum cycle time (a.k.a. cycle monitoring time) must always be set higher than the longest actual cycle time measured for the current user program. The default is 150 ms on most S7-300 CPUs (CPU 313C/314/315/317 family) and 6000 ms on S7-1200 CPUs, but both are configurable in the CPU properties under Cycle Time > Maximum Cycle Time.

The exact behavior is platform-specific:

Per the STEP 7 V20 S7-1200 functional description on cycle time: "If the cyclic program exceeds the maximum cycle time, the operating system will attempt to start the time error OB (OB 80). If the OB is not available, the S7-… will go to STOP." The same rule applies to S7-300/400 in STEP 7 V5.x and to S7-1500 in TIA Portal.

Important nuance on S7-300/400: a double exceed (i.e., the cycle time exceeds 2× the configured maximum) is treated as a hard fault and goes to STOP even if OB 80 exists. This is documented in the S7-300 CPU 31x/319F manuals under Cycle and Reaction Times.

Typical Root Causes

Cycle time exceeded faults fall into four categories. Before refactoring code, confirm the category using the diagnostic buffer and the online scan time monitor.

1. Algorithmic overload in OB 1. Heavy numerical work (matrix inversion, N×N matrix math, polynomial fits, FFT, large FOR loops) executed in a single scan. This is the most common cause when simulation runs fine but the real CPU faults: PLCSIM on a workstation executes the same instructions in microseconds, while the real CPU executes them in tens of milliseconds, exposing the budget breach.
2. Infinite or runaway loops. A FOR / WHILE / REPEAT / SCL loop whose exit condition is never satisfied. The CPU watchdog trips before the loop terminates. Examples include divisions where the divisor approaches zero, counters that never increment, or an IF inside a loop that re-triggers the same branch.
3. Communication stack starvation. Too many simultaneous PG/HMI/OPC-UA/S7 connections, large PUT/GET payloads, BSEND/BRCV calls without handshake, or unacknowledged TSEND/TRCV jobs. The communications OB adds wall time to the cycle.
4. Edge cases in cyclic interrupt OBs. OB 30–OB 38 (S7-300/400) and the equivalent on S7-1200/1500 that run faster than OB 1 can finish. If a 2 ms OB 35 is configured and its execution exceeds 2 ms, OB 80 fires; if OB 35 exceeds 2× its period, the CPU goes to STOP regardless of OB 80.

Diagnostic Workflow

1. Capture the diagnostic buffer. In TIA Portal: Online > Online & Diagnostics > Diagnostics Buffer. Look for an event with text "Cycle time exceeded" or "Time error OB (OB 80)". Note the OB that triggered it (OB 1 vs. OB 35), the actual measured cycle, and the configured maximum.
2. Measure the OB 1 time online. Use Online & Diagnostics > Cycle Time, or read the system clock via SFC 64 (TIME_TCK) at the start and end of OB 1 and compute the delta. Persist the values in a DB so post-mortem analysis is possible.
3. Identify the hot block. Comment out suspected heavy blocks and re-download. Better, use the S7-300/400 Profiling tool or the TIA Portal Trace function (S7-1200/1500) to record the execution time of individual blocks. A 100 ms+ jump in a single FB is the typical signature of a matrix or iterative routine.
4. Confirm in PLCSIM vs. real CPU. If PLCSIM runs and the real CPU does not, the workload is at the boundary of the real CPU's throughput. This is a sign that the algorithm is too large for a single scan on that hardware.
5. Check the watchdog configuration. Verify that the configured maximum cycle time is at least 2× the measured worst-case scan. If it is already at 6000 ms and the CPU still faults, the algorithm itself must be refactored; increasing the watchdog further is not a solution.

Resolution Strategy 1 — Load OB 80 as a Safety Net

Before fixing the algorithm, install OB 80 with at least one line of code that sets a BOOL in a non-volatile DB (retain DB or instance DB) and then returns. This achieves two things:

• It prevents a single transient exceed (e.g., a 200 ms blip during commissioning) from stopping production.
• It records the fault so you know it happened. Reset the flag in OB 1 once it has been read by the HMI or historian.

OB 80 does not, however, prevent the double-exceed hard STOP, and on a single-CPU setup it does not retry the failed cycle. Treat OB 80 as a diagnostic tool and a soft cushion, not a fix.

Resolution Strategy 2 — Spread the Work Across Multiple Scans

For numerical work that does not change every scan, the standard S7 pattern is to split the work into smaller pieces and rotate through them using a state machine in OB 1. The pattern is straightforward in SCL:

FUNCTION_BLOCK "FB_MatrixWorker"
VAR
    iState : INT := 0;          // 0 = idle, 1..N = work chunks
    iChunk : INT;               // current chunk index
    aWork  : ARRAY[1..200] OF REAL; // pre-allocated work buffer
END_VAR

CASE iState OF
  0: // waiting for new request
    IF bRequest THEN
        iState := 1;
        iChunk := 1;
    END_IF;

  1..200:
    // process one chunk of the matrix per scan
    MatrixChunk( a := aWork, i := iChunk, bResult := aWork[iChunk] );
    iChunk := iChunk + 1;
    IF iChunk > 200 THEN
        iState := 255; // done
    END_IF;

  255: // finished, set output and clear request
    bResultValid := TRUE;
    bRequest := FALSE;
    iState := 0;
END_CASE;
END_FUNCTION_BLOCK

Each scan now does 1/200th of the work, so a 200 ms matrix routine becomes 1 ms per scan and the watchdog is never threatened. The trade-off is that the result is only valid 200 scans later. If the process needs the result every 100 ms and the cycle is 10 ms, you can do 10 chunks per scan and still meet the deadline.

For long pipelines, the Siemens Open Development Kit and OSCAT library provide pre-built matrix primitives that can be scheduled in this way. OSCAT is community-vetted and ships with documented SCL sources; the Siemens-bundled matrix blocks are listed in the next section.

Resolution Strategy 3 — Use Siemens Matrix Function Blocks

Siemens ships a free library of mathematical function blocks for S7-300/400 that includes matrix operations, root finders, integrators, and statistical functions. The blocks are documented in "Operationen Bausteine" (entry ID 29851674) on the Siemens Industry Online Support portal. The matrix blocks implement the operations with fixed-size arrays and avoid the heap-allocation cost that MATLAB/Simulink-generated code carries on a real CPU.

These blocks are designed for cyclic execution and can be split across scans by passing partial results. When migrating from MATLAB/Simulink, replace the auto-generated M-files with these primitives; the MATLAB-generated code is not optimized for SCL and often produces nested loops that scale as N^3 or worse.

Resolution Strategy 4 — Move Heavy Math Off the PLC

If the matrix is needed for a value that the operator sees but the process does not control (a trend, a recipe preview, a quality KPI), move the math to the HMI or a separate industrial PC. Comfort panels, WinCC, and TIA Portal Unified HMI panels all support VBScript, C scripts, or the HMI-side SCL that can compute the result without burdening OB 1. The HMI can also be the master for a one-second or one-minute recompute cadence, in which case the PLC only needs to provide the raw inputs.

This is a legitimate architecture choice when:

• The result is consumed by a human, not a control loop.
• The result feeds a setpoint that updates at 1 Hz or slower.
• The PLC must reserve its cycle for I/O, drives, and safety.

Resolution Strategy 5 — Tune OB 35 and Other Cyclic Interrupts

Cyclic interrupt OBs (OB 30–OB 38 on S7-300/400) run at a fixed period and have their own implicit watchdog: if the OB exceeds 2× its configured period, the CPU goes to STOP. Common mistakes:

• Setting OB 35 to 2 ms but executing 5 ms of math inside it.
• Sharing the same FB instance between OB 1 and OB 35, causing two simultaneous executions to contend for the same resources.
• Forgetting to load OB 80; a single 4 ms blip in OB 35 will then stop the CPU.

Right-size OB 35 to the math. A 50 ms OB 35 with a 40 ms body is safe; a 2 ms OB 35 with the same body is not. If the math is heavy, push it to OB 1 with chunked execution and let the cyclic interrupt handle only the I/O scan.

Step-by-Step Refactor Procedure

1. Create a watchdog DB. Add a retain DB with a bCycleFault BOOL. Load OB 80 and set the flag in it. This is your safety net.
2. Measure current scan. Run the program online, read SFC 64 ticks at the start and end of OB 1, log the maximum for 1 hour. The maximum is the true budget you must beat.
3. Profile the heavy FB. Use the TIA Portal Trace or an internal SFC 64 sample in the FB itself to record the FB's execution time. Confirm it is the dominant cost.
4. Choose a strategy. If the FB does N units of work in one scan, decide: chunk across N scans, substitute a Siemens matrix FB, move the work to the HMI, or upgrade the CPU.
5. Implement chunked execution. Add a state machine inside the FB. Keep the input contract unchanged so callers do not need to know the work is now asynchronous.
6. Verify online. Download, go online, force a request, and watch the cycle time monitor. The maximum should drop well below the watchdog. Confirm the result is produced within the required latency.
7. Document the new cycle budget. Update the HMI diagnostic page to show the actual scan, the configured maximum, and the OB 80 latch. Operators should see whether the system is running with margin.

Verification Checklist

Troubleshooting Matrix

When to Upgrade Hardware

Sometimes the algorithm genuinely cannot be chunked (a control loop that needs the result every 5 ms) and the budget is too tight. In that case, a CPU upgrade is the correct answer. Comparison of typical S7-300/1200 bit-operation throughput:

For pure matrix math, a 319-3 or 1515-2 is roughly 10–20× faster than a 313C. If a refactor would compromise a hard real-time deadline, that upgrade pays for itself quickly in commissioning time and reduced stoppages.

Frequently Asked Questions