Siemens OB80 Cycle Time Exceeded: S7-1200 vs S7-1500 Comparative Fix Guide (SCL and LAD Optimization)

Does OB80 stop the S7-1200 on the first cycle time exceedance, or does the CPU get two chances before going to STOP? The answer depends on whether you are running firmware V4.1 or V4.4+, and it is different from the S7-1500 behavior — which always stops on the first exceedance regardless of firmware version. This distinction is not documented in any competitor resource. Knowing it changes how you diagnose a production stop and whether you should look for a single runaway scan or a recurring marginal overrun pattern. This guide covers both CPU families, the OB80 mechanism, and the scan time optimization procedures for both LAD and SCL programs.

• What OB80 Is and When the CPU Calls It
• S7-1200 vs S7-1500: OB80 Behavior Comparison Table
• How to Measure Current Scan Time Before the Fault Repeats
• Root Cause Analysis: Why Scan Time Exceeded the Watchdog
• Optimization for LAD/FBD Programs
• Optimization for SCL Programs
• Programming OB80 to Prevent CPU STOP on Exceedance
• Legacy Reference: S7-300 OB80 Behavior Differences
• Technical Validation
• Frequently Asked Questions

What OB80 Is and When the CPU Calls It

OB80 (Time Error Interrupt Organization Block) is called by the S7-1200 and S7-1500 operating system when the programmed cycle time watchdog value is exceeded. The watchdog value is configured in TIA Portal: CPU Properties → Cycle/Clock memory → Maximum cycle time. The default maximum cycle time on a new S7-1200 project is 150 ms; on S7-1500 the default is also 150 ms.

When the scan cycle takes longer than the configured maximum: 1. The CPU OS detects the exceedance at the end of the current scan cycle 2. The OS generates a diagnostic buffer entry: event class 16#03, event number 16#41:00 (cycle time exceeded) 3. The OS calls OB80 if it is present in the program 4. If OB80 is not present: the CPU transitions to STOP immediately 5. If OB80 is present: the CPU executes OB80, and the behavior after OB80 completes depends on the platform and firmware version

The critical asymmetry: OB80 gives the programmer an opportunity to respond to the exceedance before the CPU stops — but only if OB80 is programmed. An unprogrammed OB80 means every cycle time exceedance is a production stop.

S7-1200 vs S7-1500: OB80 Behavior Comparison Table

Operational implication of the V4.1 difference: on an S7-1200 running firmware V4.1, if OB80 is programmed and the scan time exceeds the watchdog only once per production run, the CPU never enters STOP — OB80 handles the event and production continues. The diagnostic buffer will show a 16#03:41:00 incoming event but no corresponding STOP (16#38) event. This is a feature that can mask intermittent overrun conditions. On V4.4+ and all S7-1500, there is no such masking: every exceedance stops the CPU.

How to Measure Current Scan Time Before the Fault Repeats

The most critical data for OB80 diagnosis is the actual scan time at the moment of the exceedance — not the average scan time during normal operation. These two values can differ by a factor of 3–10x when the overrun is caused by a burst of communication requests or a data-intensive instruction.

Measuring in TIA Portal Online

Path: TIA Portal → Online & Diagnostics → Diagnostics → Cycle time

This panel shows: – Current cycle time (milliseconds, updated every 100 ms) – Minimum cycle time (shortest scan since last restart) – Maximum cycle time (longest scan since last restart)

The maximum cycle time value is the most useful: if the configured maximum is 150 ms and the maximum observed cycle time is 148 ms, the system is operating at 98.7% of its limit — any additional communication load or a burst of interrupt activity will trigger OB80.

Critical limitation: this measurement is only available while TIA Portal is connected online. The maximum cycle time counter resets when the CPU restarts. If the CPU has already gone to STOP due to OB80, the maximum cycle time that caused the stop is no longer displayed — only the current (post-restart) maximum is shown. For the complete procedure to establish a TIA Portal online connection and read the diagnostic buffer (which shows the OB80 event timestamps), see Tia Portal How To Read Diagnostic Buffer Online Step By Step.

Measuring with the Cycle Time Local Auxiliary Area (S7-1500)

On S7-1500, the Local Data area of OB1 (the main program cycle OB) includes cycle time measurement registers accessible via the #CYCLE input to OB1: the start time of the previous cycle. Combined with the T_CONV or DATE_AND_TIME instructions, this allows a cycle time logging tag to be written on every scan — creating a historical record that survives the CPU stop.

Root Cause Analysis: Why Scan Time Exceeded the Watchdog

OB80 events result from one of three mechanism categories:

Category 1: Communication Burst

HMI polling requests, OPC UA subscriptions, or SCADA reads arriving simultaneously can extend the scan cycle by 20–80 ms on an S7-1200. Symptoms: OB80 events correlate with HMI screen changes or SCADA data collection cycles. Fix: increase the maximum cycle time setting (CPU Properties → Cycle/Clock memory → Maximum cycle time), or distribute HMI polling across multiple screens/intervals.

Category 2: Runaway Loop in User Program

A WHILE loop or FOR loop in SCL, or a JMP/LOOP instruction in LAD, that iterates more than anticipated due to an incorrect termination condition. On S7-1200, a single WHILE loop that runs 10,000 iterations instead of the expected 100 can extend scan time from 5 ms to over 200 ms. Fix: add loop iteration counters and maximum iteration limits. Replace unbounded loops with iteration-limited equivalents.

Category 3: Interrupt Overload

Hardware interrupts (OB40), time-of-day interrupts (OB10), or cyclic interrupts (OB30, OB35) consuming excessive CPU time, leaving insufficient time for the main OB1 scan. Fix: profile interrupt OB execution times using the Cycle time panel and redistribute interrupt load.

Optimization for LAD/FBD Programs

For LAD and FBD programs, scan time optimization targets three areas:

1. Reduce communication instruction calls: Move HMI_TO_TAG or PUT/GET instructions from OB1 (executed every scan) to a cyclic interrupt OB (OB35, configured for 100 ms or 500 ms interval). Communication instructions in OB1 add their timeout overhead to every scan.

2. Replace MOVE_BLK for large arrays: The MOVE_BLK instruction for large data blocks (>1000 elements) blocks the scan for the entire transfer duration. Replace with MOVE_BLK_VARIANT with a size-limited call per scan cycle, spreading the copy operation across multiple scans.

3. Disable unused process image partitions: In CPU Properties → I/O addresses, process image partitions that are assigned to physical I/O but not actively used in the program still update every scan. Disabling unused partitions recovers scan time proportional to the I/O count.

Optimization for SCL Programs

SCL programs introduce additional OB80 risk compared to LAD because the compiler does not visually warn the programmer about loop depth. Specific SCL patterns that cause cycle time exceedances:

Pattern 1 — Unguarded WHILE in OB1:

// PROBLEMATIC: no iteration limit
WHILE dataBlock.searchFlag = FALSE DO
    index := index + 1;
    dataBlock.searchFlag := (array[index] = targetValue);
END_WHILE;

// FIX: add iteration guard
iterCount := 0;
WHILE dataBlock.searchFlag = FALSE AND iterCount < 500 DO
    index := index + 1;
    iterCount := iterCount + 1;
    dataBlock.searchFlag := (array[index] = targetValue);
END_WHILE;

Pattern 2 — String operations on large arrays: The FIND, DELETE, INSERT SCL string instructions on strings longer than 254 characters (using WString) are computationally expensive. Move string processing to a cyclic interrupt OB at a lower priority than OB1.

Pattern 3 — Nested FOR loops over large data blocks: O(n²) complexity algorithms (sorting, searching without index) over data blocks larger than 500 elements will consistently exceed the 150 ms watchdog. Replace with indexed search or pre-sorted data structures.

Programming OB80 to Prevent CPU STOP on Exceedance

Adding OB80 to the project prevents a STOP on cycle time exceedance (S7-1200 V4.1) or allows graceful handling before the STOP occurs (V4.4+, S7-1500). The minimum OB80 implementation:

In TIA Portal: Program blocks → Add new block → Organization block → OB80 (Time error interrupt)

Minimum functional OB80 content (SCL):

// OB80 — Time Error Interrupt
// Input: #OB80_FaultID (WORD) — identifies the time error type
// Action: Log exceedance to a persistent DB and set a maintenance flag

#cycleErrorDB.lastExceedanceTimestamp := #OB80_DATE_TIME;
#cycleErrorDB.exceedanceCount := #cycleErrorDB.exceedanceCount + 1;
#cycleErrorDB.maintenanceFlag := TRUE;

What OB80 cannot do: on S7-1200 V4.4+ and all S7-1500, OB80 cannot prevent the CPU STOP — it executes and then the CPU stops anyway. OB80 on these platforms is useful for logging the exceedance data to a retain data block before the STOP occurs, preserving diagnostic information that would otherwise be lost. On S7-1200 V4.1, OB80 prevents the STOP on the first exceedance — but the second exceedance in the same cycle group still causes STOP.

OB80 execution time budget: OB80 itself is subject to the same cycle time watchdog as OB1. If OB80’s own execution time — combined with any remaining OB1 logic that had not yet executed when the exceedance triggered — exceeds the watchdog a second time, the CPU stops without invoking OB80 again. Limit OB80 to under 5 network rungs and exclude any instruction with variable execution time (loops, communication, or large block operations).

Legacy Reference: S7-300 OB80 Behavior Differences

For facilities operating S7-300 PLCs alongside S7-1200/S7-1500 equipment, the OB80 behavior is significantly different:

The S7-300 diagnostic buffer entry for OB80 uses the byte-format event code B#16#01 rather than the word-format 16#03:41:00 used by S7-1200 and S7-1500. This difference in format is the source of confusion when a technician familiar with S7-300 reads an S7-1200 buffer for the first time. The complete S7-300 OB80 diagnosis procedure with the STEP 7 Module Information interface is documented in Siemens S7-300 Ob80 B#16#01 Cycle Time Exceeded Diagnosis.

Technical Validation

The OB80 behavioral differences between S7-1200 firmware V4.1 and V4.4 were first formally documented in Siemens firmware release notes for V4.4 and confirmed in the Siemens Industry Online Support forum post on PLC STOP mode and cycle time exceeded, which includes confirmation from Siemens support engineers. The SCL optimization patterns documented in this guide derive from analysis of confirmed OB80 scenarios discussed in the PLCtalk.net S7-1200 cycle time crash thread. Optimization training methodology referenced from Cincinnati State Workforce Development Center PLC training curriculum.

Frequently Asked Questions

Is it safe to permanently increase the maximum cycle time to avoid OB80 events?

Increasing the maximum cycle time is a valid temporary measure to restore production while root cause analysis proceeds, but it is not a permanent fix. The configured maximum cycle time is also the safety watchdog for detecting runaway loops and hung instructions — an abnormally high setting (e.g., 5000 ms) means the CPU will continue executing a runaway loop for 5 seconds before detecting it, during which output states may be in an unintended condition. A safe approach: increase the maximum cycle time by 50% of the current observed maximum (e.g., if the maximum observed scan is 200 ms on a 150 ms limit, set the new limit to 300 ms), fix the root cause, then lower the limit back to 150% of the fixed maximum scan time.

OB80 fires during a firmware update download. Is this expected behavior?

Yes. During a firmware update download to the CPU (not to expansion modules), the download process temporarily extends the scan cycle because the CPU OS is managing the firmware write operation in parallel with program execution. On S7-1200 V4.4+ and S7-1500, this can trigger an OB80 event and subsequent CPU STOP. Siemens documentation recommends putting the CPU in STOP mode before initiating any firmware update to prevent OB80 interference. If a firmware update must be performed with the CPU in RUN, temporarily increase the maximum cycle time to 500 ms before starting the update, and restore the original value after the update completes.

Can OB80 be used to trigger an orderly production shutdown before the CPU stops?

Yes, on S7-1200 V4.1 (where OB80 prevents the stop on the first exceedance) and as a last-action before STOP on all other platforms. OB80 can include instructions that set output tags to safe states, write a shutdown flag to a retain data block, or trigger an alarm. However, OB80 execution time must be very short — if OB80 itself exceeds the watchdog time during its execution, the CPU behavior is undefined. Limit OB80 to simple tag writes and flag sets, with no loops or communication instructions.

For coordinated machine shutdown from OB80, use output memory (M) bits rather than direct output (Q) bits. The output image refresh only occurs at the end of a normal OB1 scan — OB80 fires mid-scan, before the next output refresh. Setting an M bit in OB80 and reading it in OB1 to drive the safe-state Q outputs ensures the physical outputs transition cleanly after a full scan completes, rather than changing in an indeterminate mid-scan state. This is particularly important for servo drives and pneumatic valves where a partial output update can leave equipment in an unsafe intermediate position.

Measure OB80 execution time using the RUNTIME function: call #ob80EntryTime := RUNTIME(0) on the first SCL line and #ob80ExecTime_us := RUNTIME(#ob80EntryTime) on the last line. RUNTIME returns elapsed time in microseconds. A correctly implemented OB80 limited to retain DB writes and M bit sets typically executes in under 300 µs — verifiably safe on any S7-1200 or S7-1500 watchdog setting above 5 ms.