S7-300/400 OB1 Maximum Cycle Time: Configuring 150ms Monitoring

Overview

OB1 is the main cyclic organization block executed by every Siemens S7-300 and S7-400 CPU on each scan. The operating system imposes a configurable upper bound on the OB1 execution time to guarantee a bounded process response time and to detect runaway logic. Exceeding that bound is treated as a fatal condition: the OS calls OB80 (Time Error OB), and if OB80 is missing or itself fails, the CPU transitions to STOP.

The default value of 150 ms is shipped from the factory and applies to virtually every S7-300 CPU (CPU 312 through CPU 319) and every S7-400 CPU (CPU 412 through CPU 417) unless the engineer explicitly changes it. This reference explains how the watchdog works, how to size the limit to the process, what OB80 does, how SFC43 RE_TRIGR can extend the apparent budget, and what the absolute upper limits are when OB1 has heavy work to do.

OB1 Cycle Time Architecture in S7-300/400

The S7-300/400 scan is layered. Each pass of OB1 runs in this order:

1. Process image of inputs (PII) is updated.
2. OB1 user program executes from the first network to the last.
3. Process image of outputs (PIQ) is written to the physical outputs.
4. Operating system housekeeping: communication, self-test, time-tick, priority-class scheduling.

The cycle time the OS measures starts when OB1 begins and stops when OB1 ends. Communication OBs (OB35-equivalent tick, OB40–OB47 hardware interrupts, OB82 diagnostic, OB100 warm restart, OB101 hot restart, OB102 cold restart) do not count against OB1's timer because they interrupt OB1 with their own priority class. The OB1 timer is purely a watchdog against OB1 itself, not against the total CPU scan.

The 150 ms Default Value - Why It Matters

Siemens chose 150 ms as the factory default because most discrete-machine applications (conveyors, packaging, small assembly cells) need cycle times well under 100 ms to feel responsive. The 150 ms threshold gives a 50% safety margin for occasional spikes while still catching genuine runaway code within a fraction of a second - fast enough that a stuck output is unlikely to cause damage to the machine or product.

The 150 ms figure is not a hard physical limit of the CPU. It is a soft, configurable engineering parameter. CPUs in the S7-300 family (CPU 312, 312C, 313, 313C, 314, 314C, 315, 315-2 DP/PN, 317-2 DP/PN, 319-3 PN/DP) and S7-400 family (CPU 412-1/2, 414-2/3, 416-2/3, 417-4) all share the same HW Config dialog for the parameter, although some newer S7-300 CPUs (e.g. CPU 315-2 PN/DP, 6ES7315-2EH14-0AB0 with firmware V3.3 and higher) may display a slightly different layout where the parameter is split into Scan cycle monitoring time and Communication load.

Configuring the Maximum Cycle Time in HW Config

Open the S7 project in STEP 7 (V5.x) or SIMATIC Manager, expand the S7 station, double-click Hardware to open HW Config, then double-click the CPU (for example 6ES7 315-2AG10-0AB0). Navigate to the Cycle/Clock Memory tab. The relevant field is labelled Scan cycle monitoring time with the unit milliseconds and a default value of 150.

1. Open SIMATIC Manager and load the station.
2. Launch HW Config.
3. Double-click the CPU icon in the rack to open the Properties dialog.
4. Select the Cycle/Clock Memory tab.
5. Locate the field Scan cycle monitoring time (German: Zyklusüberwachungszeit).
6. Enter the new value in ms. Valid range is 1 ms to 6000 ms.
7. Confirm with OK and save/compile the hardware configuration back to the CPU or to the offline project.

The new value takes effect after the next STOP-to-RUN transition, after a cold restart (OB102), or - depending on CPU firmware - immediately on download while the CPU is in RUN. If you change the value online via STEP 7 PLC > Change Operating Mode or via the SFC afterwards, the new value is non-volatile on most S7-300 CPUs but volatile on some S7-400 CPUs. Refer to the CPU-specific manual for the persistence behaviour of the parameter.

OB80 - Time Error Organization Block

OB80 is the dedicated response to a cycle-time violation. When OB1's elapsed time exceeds the configured scan cycle monitoring time, the OS:

1. Suspends OB1 at the current instruction.
2. Calls OB80 synchronously - meaning OB80 runs at higher priority and finishes before OB1 is allowed to continue.
3. Passes to OB80 a temporary local data block (L-stack) containing the start-up information, the OB that exceeded its time (always OB1 in this scenario), the configured maximum, and the actual elapsed time.

The OB80 start information is laid out as follows:

If OB80 is missing in the S7 program (i.e. never downloaded to the CPU), the OS reacts with a STOP - the diagnostic buffer records STOP caused by missing OB80 or STOP due to time error and the SF (system fault) LED lights red. If OB80 exists but itself takes longer than twice its configured time, the OS calls OB80 again; if that second call also fails to complete in time, the CPU goes to STOP unconditionally.

SFC43 RE_TRIGR - Restart the Time Watchdog

SFC43 RE_TRIGR is the standard function the engineer calls from within OB1 (or any other lower-priority OB) to reset the cycle-time watchdog. After the call, the OS starts a fresh monitoring window from the moment of the call. Use cases include:

• Long, deterministic startup initialisation in OB100 that legitimately takes more than 150 ms.
• A one-shot recipe download that is rare and known to overrun.
• An engineering diagnostic pass that should not fault the CPU while it runs.

SFC43 has no inputs and no outputs - it is purely an instruction to the OS. Call it from STL or SCL like any other SFC:

In ladder logic, drop the FC/SFC call box and enter SFC43 (or RE_TRIGR). The SFC has no EN/ENO conventions to worry about; it always succeeds.

The 2x Rule - Why the Second Timeout Is Fatal

The OS does not allow SFC43 to extend the monitoring window indefinitely. The rule is:

1. OB1 begins. The watchdog starts.
2. OB1 calls SFC43 - the watchdog resets and starts fresh.
3. OB1 continues and exceeds the configured time again.
4. The OS calls OB80 a second time, in the same OB1 pass.
5. If OB80 itself cannot finish within the configured time, the CPU goes to STOP.

This means even with SFC43, OB1 cannot be allowed to run for more than 2 x (configured maximum) within a single OB1 execution. In practice you should leave a comfortable margin and never approach the boundary.

Absolute Upper Limits

The HW Config field accepts values from 1 ms up to 6000 ms (six seconds). This is a hard maximum regardless of CPU model. Combined with the 2x rule, the longest OB1 the OS will tolerate is therefore:

If you need OB1 to do more work than that, you must restructure the program - for example, break the work into OB35 cyclic interrupts at, say, 100 ms each, or move heavy data handling to OB100 (startup) and only execute it once.

Why the OS Fails Hard, Not Soft

The OS treats an unhandled OB80 the same way it treats a missing or failed safety-relevant OB: it transitions to STOP. The rationale is that if OB1 is taking too long, the process image of outputs has not been refreshed, and outputs are frozen at their last-written state. For most discrete control (motor contactors, valves) a frozen output for more than a fraction of a second is hazardous. The OS chooses the conservative interpretation: assume the worst, halt everything, force the engineer to investigate.

Practical consequences on the plant floor:

• SF (system fault) LED solid red, BF (bus fault) off, RUN LED off, STOP LED on.
• Diagnostic buffer entry: STOP caused by time error OB (OB80) - cycle time exceeded.
• All outputs go to their configured substitute/keep-last state as set in HW Config under the I/O module properties.

Sizing the Limit from Process Requirements

Engineers commonly pick a value from the top down (set 150 ms and hope) when they should pick from the bottom up. Use this calculation:

Step 1 - Measure the worst-case OB1. Open the CPU online in STEP 7, choose PLC > Module Information > Performance (or in newer toolchains Online > Diagnostics > Cycle Time). The longest of OB1 min / OB1 max / OB1 current is your minimum required monitoring time. Add 25% headroom:

Step 2 - Add communication load. Communication OBs do not extend OB1 directly, but they steal CPU share and can cause OB1's measured time to grow when PROFINET or PROFIBUS traffic peaks. If you have a PN/PN coupler, OPC UA server (in newer CPUs like CPU 1500 successor series - not relevant here), or aggressive PG routing, add another 20–30%.

Step 3 - Round up to a clean number. Typical choices: 200 ms, 300 ms, 500 ms, 1000 ms, 2000 ms. Avoid non-round values like 137 ms.

Step 4 - Confirm the OB80 strategy. Decide explicitly whether OB80 will simply log and reset, set a global fault flag, or trigger an orderly shutdown sequence. Document the decision in the program header.

Practical Calculation Examples

Example 1 - Small packaging machine. Measured OB1_max = 18 ms. Communication load = 5%. Target = 1.25 × 18 × 1.05 ≈ 24 ms. Round up and keep the default 150 ms; do not lower it below 50 ms without strong justification.

Example 2 - Large batch reactor with recipe arrays. Measured OB1_max = 850 ms (during recipe step transitions). Communication load = 15% via PROFIBUS to remote ET 200M. Target = 1.25 × 850 × 1.15 ≈ 1222 ms. Set the HW Config value to 1500 ms. Do not rely on SFC43 - move the recipe math into OB35 @ 200 ms and have OB1 only orchestrate state.

Example 3 - Cold-start initialisation. The first scan after power-on needs to read 2000 lines of a recipe from MMC and write to DB. The OB1 pass takes 8 seconds. Configure monitoring time to 6000 ms, call SFC43 immediately on entry to OB1 only on the first scan (use a one-shot flag in a static DB), then revert to the normal value at runtime via the OB80 handler.

Troubleshooting Matrix

Related Time-Watchdog Mechanisms

OB1 is not the only cycle the OS monitors. Be aware of these adjacent mechanisms when debugging time errors:

• OB35 cyclic interrupt watchdog: configured under the same HW Config tab. Default 100 ms. Use the same SFC43 strategy.
• Communication load percentage: a separate HW Config parameter that caps the CPU share given to communication tasks (e.g. HMI polling, S7 communication, OPC). Values above 50% will starve OB1.
• Startup OBs (OB100/101/102): have a fixed timeout of about 100 seconds on S7-300 and S7-400; if startup logic overruns that, the CPU goes to STOP with a different diagnostic code.
• DPV1 / PROFINET diagnostics: a heavy diagnostic storm (e.g. a chassis with a failing module) can dominate OB82 handling and indirectly slow OB1.

Commissioning Checklist

1. Open STEP 7 and connect online to the CPU.
2. Read PLC > Module Information > Performance; capture OB1_min, OB1_max, OB1_current.
3. Read the diagnostic buffer; record any time-error events.
4. Open HW Config; on the CPU's Cycle/Clock Memory tab, set Scan cycle monitoring time to the calculated T_watch.
5. Save and compile; download the hardware configuration.
6. Confirm the new value via PLC > Module Information > Performance after a STOP-to-RUN transition.
7. Run the process through its worst-case workload for at least one full production cycle; verify the OB1_max stays under the configured limit.
8. Document the chosen value, the rationale, and the OB80 strategy in the project documentation.

FAQ