S7-300 Timer Overload: Resolving 300 I/O Delays in STEP 7

S7-300 Timer Overload: Resolving 300 I/O Delays in STEP 7

When an S7-300 CPU is forced to drive delay logic for 200 digital and 100 analog inputs, the combination of limited on-board timer cells, OB1 scan overhead, and HMI re-triggering can push the cycle time past 180 ms. This reference explains the three viable patterns — native S7 timers, IEC SFB multi-instances, and a custom INT decrement in OB35 — and shows how to select, program, and verify each one without exhausting the CPU's work memory or its timer/counter resource pool.

1. Problem Definition: Why 300 Delay Timers Break a 314/315 CPU

The S7-300 family (CPU 312 through CPU 319, plus the CPU 31x instruction list) implements on-delay (SD), off-delay (SF), pulse (SP), extended pulse (SE), retentive on-delay (SS) and stored off-delay (SA) instructions through a fixed table of timer words in the system memory. Each active instance consumes one 16-bit timer cell, and exceeding the cell count raises a synchronous error that is dispatched to OB 121 if it exists, otherwise the CPU goes STOP. The TIA Portal functional description for S7-300/400 confirms this behavior:

"If you use more timers and counters in your user program than the CPU permits, a synchronous error is signaled and organization block OB 121 is started." — Timers and counters (S7-300, S7-400)

With 300 input-driven delays the engineer therefore faces two independent ceilings:

Cell counts are guideline values — the exact number appears in the CPU's Module Information → Performance Data screen in STEP 7 or the TIA Portal device view. A program that creates 300 simultaneous on-delay instances through L "S5T#2s"; SD T1; ... is not bounded by code size, but by the size of the timer word table. Even when the table is large enough, the cycle time grows roughly linearly with the number of SD/SF/SP calls executed in OB1 because each instruction walks the timer base in the system tick interrupt (OB 35 minus priority) and updates the EI, DE, and RLO flags per call.

2. Root-Cause Analysis: Cycle Time vs. Memory

For a CPU 314, the worst-case scan profile for 300 on-delay calls is:

Numbers are field-typical for a CPU 314C-2 PN/DP with firmware V3.3 and STEP 7 V5.5 SP2; newer CPU 315-2 PN/DP (firmware V3.2) cuts the per-call cost to roughly 1.5 µs. Even on a 319-3, a 300-instance SD array costs measurable throughput because the timer base update is centralized in the system tick, not distributed across SD calls.

The cure is therefore not "fewer timers" — it is "fewer OB1 calls per scan." All three engineering patterns below attack that single constraint.

3. Solution A — Use S7 Timer Cells (Fastest, Cell-Limited)

The S7 on-delay SD, off-delay SF, pulse SP, extended pulse SE, stored on-delay SS, and stored off-delay SA instructions are translated by STEP 7 into native microcode that runs in single-digit microseconds. They are the fastest path, but each active call binds a timer cell T0–Tn from the system memory.

Use this pattern when the number of concurrently active delays fits in the cell table, even if the total set of logical delays is larger. Two techniques help:

1. Time-slice sharing. Reuse the same timer cell across multiple inputs by checking the input at the start of SD execution, copying its state to a DB flag, then immediately resetting the timer. Only one cell is needed for n inputs if their delays are scheduled sequentially.
2. Pre-divide long delays. An S7 timer has a base resolution of 10 ms and a maximum value of S5T#2H_46M_30S (9990 s). If your delay is a 30-minute cycle for a slow analog filter, run a 1-second SE and count edges in a CTU block.

Example — ladder call that shares timer T17 across eight digital inputs:

// FB100 — "Share_T17"
A "DI_b0.0"; L S5T#500MS; SD T17; A T17; S "DO_dly_b0.0"
A "DI_b0.1"; L S5T#500MS; SD T17; A T17; S "DO_dly_b0.1"
... (repeat per input) ...
// At end of FC, clear unused T17 to free the cell
A "DI_b0.0"; AN "DI_b0.0"; R T17   // RLO=0 → no reset conflict

Per the S7-300 instruction list (CPU 31x), the typical execution times for timer operations on a CPU 315-2 DP (firmware V3.x) are:

These figures confirm the engineering rule: on a CPU 315-2 DP, 300 SD calls cost ~120 µs, which is dwarfed by the 12 ms HMI acyclic read overhead. The 180 ms figure in the field report is therefore almost certainly dominated by the HMI re-trigger storm, not by the timer instructions themselves.

4. Solution B — IEC Timers via SFB4/SFB5 with Multi-Instances

The IEC 61131-3 timer blocks SFB 3 (TP — pulse), SFB 4 (TON — on-delay) and SFB 5 (TOF — off-delay) are not bound to the timer cell table — they store their state in instance DBs. The limit is the available work memory and the maximum number of instance DBs the CPU permits (default 6000 on a 317-2, 8000 on a 319-3). Multi-instance capability means a single parent FB (for example FB 200 "DI_delay_block") can call SFB 4 as a static local instance, and the parent FB can itself be called 300 times from OB1 with each call producing a new multi-instance inside the same parent IDB.

This consumes exactly one DB number (the IDB of FB 200) for 300 TON instances — drastically reducing DB fragmentation and avoiding the "Number of instance DBs exceeded" diagnostic.

4.1 Defining the parent FB

In STEP 7 V5.x, declare the static section of FB 200:

FUNCTION_BLOCK FB 200
VAR_INPUT
  IN_signal : BOOL;
  PT       : TIME;     // preset time
END_VAR
VAR_OUTPUT
  Q        : BOOL;
  ET       : TIME;     // elapsed time
END_VAR
VAR
  TON_1    : SFB 4;    // multi-instance; no separate IDB required
END_VAR
BEGIN
  // call SFB 4 with this DB as the instance
  CALL TON_1   (IN := IN_signal, PT := PT);
  Q := TON_1.Q;
  ET := TON_1.ET;
END_FUNCTION_BLOCK

Generated IDB layout (typical 32 bytes per SFB 4 multi-instance):

300 calls × 32 bytes = 9.6 KB of IDB. A CPU 314 with 128 KB work memory (96 KB code, 32 KB data) accommodates this without complaint; a CPU 312 with 16 KB data may approach its instance-DB limit. Use a CPU 314C-2 PN/DP or higher when running this pattern at full scale.

4.2 Calling the parent 300 times from OB1

FUNCTION FC 100 : VOID
VAR_TEMP
  i : INT;
END_VAR
BEGIN
  FOR i := 1 TO 200 DO
      CALL FB 200, DB 200   // same DB, multi-instance array via UDT200 + AR2
        ( IN_signal := DI_word[i].bit0,
          PT       := T#500MS );
  END_FOR;
END_FUNCTION

The block above uses a UDT-based AR2 pointer walk to step through 200 multi-instance slots in a single shared IDB 200. STEP 7 generates the necessary register reload between calls. This pattern is documented in the Siemens support entry "Using multi-instances in S7-300/400" and is the canonical cure for "too many timer DBs."

5. Solution C — Custom INT Decrement in OB35 (No SFB, No Timer Cell)

When both the timer cell table and the work memory for IEC SFBs are saturated, the engineer can implement a software TON using a DINT or INT countdown driven by a time-of-day interrupt (OB 10) or a cyclic interrupt (OB 35). The pattern keeps a DB 300 "delay_array" of 300 INT words; OB 35 decrements each non-zero word by 1 every tick and writes TRUE to a corresponding BOOL output when the value reaches zero.

5.1 Data block layout

DATA_BLOCK DB 300
  STRUCT
    cnt    : ARRAY[1..300] OF INT;   // counts ticks; 0 = inactive
    preset : ARRAY[1..300] OF INT;   // 1 tick = 100 ms with OB35@100ms
    out    : ARRAY[1..300] OF BOOL;  // TRUE when cnt=0 and started
  END_STRUCT;
END_DATA_BLOCK

5.2 OB 35 dispatcher

ORGANIZATION_BLOCK OB 35
VAR_TEMP
  info  : OB_CYCLIC_INFO;
  i     : INT;
END_VAR
BEGIN
  info := OB35_INFO_ACTUAL;   // not a real SCL call; use SFC 6 / SFC 64
  FOR i := 1 TO 300 DO
      IF DB300.cnt[i] > 0 THEN
          DB300.cnt[i] := DB300.cnt[i] - 1;
          IF DB300.cnt[i] = 0 THEN
              DB300.out[i] := TRUE;
          END_IF;
      END_IF;
  END_FOR;
END_ORGANIZATION_BLOCK

OB35 default period is 100 ms. Configure a custom period (e.g., 10 ms) in HW Config → CPU Properties → Cyclic Interrupts. Smaller periods raise scheduler load linearly; stay above 5 ms on a CPU 314 to avoid OB35 timeouts.

5.3 Triggering from OB1

A "DI_b0.0";
JCN _skip;
L DB300.preset[1];     // load preset (e.g. 5 for 500 ms at 100 ms OB35)
T DB300.cnt[1];
AN "DO_dly_b0.0";
R DB300.out[1];
_skip: NOP 0;

This pattern is "exotic" (as the source notes) but has the advantage of using zero timer cells and zero IEC SFB instances. Memory cost: 300 × (2 + 2 + 0.1) ≈ 1.3 KB. Cycle cost on a CPU 315-2 DP: ~0.6 ms inside OB35, none in OB1. The trade-off is the resolution (1 tick = 100 ms default), and the engineering burden of resetting out[..] when the input falls.

6. Hybrid: SFC 20 Snapshot of the Process Image

A fourth technique mentioned in the source is to use SFC 20 "BLKMOV" to copy the process image to a DB on a periodic trigger, producing a delayed view of all inputs without any per-channel timer logic. This is best suited for analog smoothing (for example, replicating the action of a first-order lag) where the "delay" is applied to a block of 100 PIWs simultaneously.

// OB35 — copy PEW 256..355 to DB 400 every 100 ms
CALL SFC 20
  ( SRCBLK := P#E 256.0 BYTE 200,
    RET_VAL := MW 100,
    DSTBLK  := P#DB400.DBX 0.0 BYTE 200 );

The HMI reads the snapshot DB instead of the live process image, achieving a single-shared "delay" for all 100 analog channels with one BLKMOV. The on-CPU cost on a CPU 315-2 DP for 200 bytes is ~22 µs per OB35 call.

7. Input-Side Filtering: Push the Delay into the Module

Before instrumenting 300 software timers, check whether the S7-300 SM modules can do the filtering in hardware. This is the cheapest fix and is often overlooked.

Open the module in HW Config → Properties → Inputs → set Input delay to 3 ms or 15 ms. Digital debounce and analog smoothing are handled in the module firmware, eliminating the corresponding software TON entirely. On a 300-point system, configuring 15 ms input delay on the SM 321 cards removes the need for ~200 of the 300 software delays and is therefore the single biggest cycle-time reduction available.

8. HMI Re-trigger Storm: The Hidden 180 ms Culprit

The source reports a 180 ms OB1 scan. With 300 native SD calls costing ~120 µs total, the timers are not the problem. The 180 ms is almost certainly caused by ProTool / WinCC flexible polling 300 tags acyclically. The fix is to switch the HMI to a polled area pointer with a single DB 500 of packed status and let the HMI read that DB in one transaction, rather than 300 individual tags.

1. Create DB 500 with 300 BOOL outputs and 300 WORD filtered analog values packed back-to-back (length 900 bytes).
2. In WinCC flexible / TIA Portal, declare a single tag with Area pointer → DB 500 and a length of 900 bytes.
3. Update DB 500 from the timer's output (single BLKMOV per scan).
4. Set the HMI acquisition cycle to 250 ms (or longer if process allows).

This collapses 300 acyclic read transactions into 1 batched read, dropping HMI-induced OB1 load from ~12 ms to ~0.4 ms — typically a 30× reduction in this category.

9. Selection Matrix

10. Step-by-Step Migration from 300 SD Calls to Multi-Instance TON

1. Inventory the existing delay calls. In STEP 7, right-click the program blocks folder and select Reference Data → Program Structure; cross-reference all SD/SF/SP/SE/SS/SA and SFB 3/4/5 calls. Note the count.
2. Verify the CPU's free timer cells. Open PLC → Module Information → Performance Data. Confirm the number of remaining S7 Timers and S7 Counters.
3. Create the parent FB. Insert FB 200 with VAR_INPUT (IN_signal, PT), VAR_OUTPUT (Q, ET), and a static TON_1 : SFB 4 in the VAR section. Compile.
4. Generate the multi-instance IDB. Open the parent FB and click Instance DB; STEP 7 prompts for a DB number (e.g. 200). Generate it.
5. Replace one SD call at a time. Inside the FC that originally held SD T17, replace it with CALL FB 200, DB 200 (...). Use a UDT walk or array index for the 200th–300th instances.
6. Disable the old SD call. Place the original SD call inside an A FALSE; segment or comment it out. Leaving it active keeps the timer cell bound.
7. Pack HMI tags. Add DB 500 with 300 BOOLs and 300 WORDs. In the HMI project, replace the 300 individual tag references with one area pointer at offset 0 length 900.
8. Set HW Config input delays. Open each SM 321 / SM 326 in HW Config, set Input Delay = 3 ms or 15 ms, and download the HW configuration.
9. Compile & download all blocks. Perform a full download; do not rely on "Download changes only" when DB structures shift.
10. Run the verification sequence below.

11. Verification

After migration, perform the following checks in order. Each must pass before moving to the next.

1. Diagnostic buffer clean. PLC → Module Information → Diagnostic Buffer must show no "Cycle time exceeded", no "OB 85 not loaded", no "Number of timers exceeded", no "Instance DB error". Any entry halts the verification.
2. Cycle time reduction. With no I/O toggling, capture the OB1 min/avg/max cycle from Module Information → Scan Cycle Time. The average must drop below 50 ms on a CPU 314, below 20 ms on a CPU 315-2 DP.
3. Work memory headroom. Performance Data → Memory: used load memory ≤ 70 %, used work memory ≤ 60 %, leaving room for HMI acyclic bursts.
4. HMI tag refresh check. In ProTool/WinCC flexible, open Tools → Tag Simulation; pulse a DI; the corresponding delayed DO must toggle within the configured preset (allow ±1 OB35 tick for the SFB approach, ±1 OB1 scan for native SD).
5. Functional timing test. For at least 10 random inputs, measure end-to-end delay with a digital scope on the SM terminal and the delayed output terminal. Compare to PT from FB 200; tolerance ±50 ms on a 1 s preset.
6. Sustained load. Force 80 % of digital inputs ON and toggle 20 % of analog channels at 4 Hz; run for 30 minutes. Diagnostic buffer must remain clean and cycle time must stay within 1.5× the static value.

12. Common Pitfalls and Field Notes

• Time-sliced SD sharing a cell. Document explicitly which inputs use which slot; lost edges are silent.
• Multi-instance parent IDB exceeded. A 300-instance parent FB produces a 9.6 KB IDB on a CPU 315-2 DP; never write to the IDB directly from a forced VAT — STEP 7 will accept the write but the next SFB 4 call will overwrite it. Use a separate UDT-based data DB.
• OB35 overrun. OB35 at 5 ms with a 600 µs decrement loop is comfortable on a 317-2 but will overrun on a 312. Raise the period to 20 ms and recompute presets, or move the decrement to a free-running counter + OB1 background task.
• Watchdog reset on timer cell overrun. If OB 121 is missing, the CPU will STOP on the first overflow. Always load OB 121 (and OB 80, OB 85, OB 86) as a hardening measure when working close to the resource limits.
• Analog "delay" semantics. A snapshot DB is a delay, not a filter. For first-order lag, replace with a true single-pole IIR: y[n] = y[n-1] + (x[n] - y[n-1]) * tau / (tau + dt) applied per channel in OB35.
• CPU 312 caveat. A CPU 312 has only 16 KB work memory and 0.1 µs per bit instruction. Pattern B (multi-instance) with 300 TONs consumes 9.6 KB of data memory plus the FB code; Pattern C is the only realistic option on this CPU.

13. FAQ