S7-300 Scan Cycle: Generating 2-Second Blink Bits with Timers

Overview

On an S7-300 CPU, ladder logic that runs cleanly on an S7-200 (STEP 7 Micro/WIN) can silently fail or latch high. The classic symptom is a two-second on/off blink bit that never toggles, that holds TRUE after the first cycle, or that the compiler refuses to load. The cause is not the scan time, the timer, or the CPU - it is the IEC 61131-3 rule set that STEP 7 V5.5 enforces on the LAD/FBD editor for S7-300 and S7-400. This reference covers the scan architecture, the network rules that break parallel-branch blink logic, the limits of the built-in clock memory byte, three field-proven methods to generate a 2 s on / 2 s off bit, and the migration path to S7-1500. The official Siemens cycle-behavior reference is here: Settings for the cycle behavior (S7-300, S7-400) - STEP 7.

S7-300 Scan Cycle Architecture

Every S7-300 and S7-400 CPU executes a fixed cycle: process image input (PII) update, OB1 cyclic scan, process image output (PIQ) update, then housekeeping (communication, self-test). The cycle is monitored by a configurable watchdog in milliseconds; exceeding the maximum cycle time forces the CPU into STOP with the SF LED on and a diagnostic buffer entry. Per the Siemens cycle-behavior documentation, the default watchdog ranges from 150 ms (CPU 312) to 6000 ms (CPU 417) depending on the CPU model.

The scan is strictly sequential within a network and strictly sequential across networks inside OB1. A timer started in network 1 evaluates its done bit (Q = 1) at the same scan only if the rung energizes the timer coil on this scan. There is no implicit edge between network 1 and network 4 within the same OB1 pass - the only state visible across networks is the bit-mapped memory (M, DB, outputs) that the previous network wrote.

IEC 61131-3 Ladder Logic Restrictions on S7-300

STEP 7 V5.5 implements the IEC 61131-3 graphical and textual languages. The LAD/FBD editor enforces two rules that Micro/WIN does not enforce on S7-200:

1. Single coil rule: a network may contain a single output coil branch. Multiple coils to the same operand in the same network is a compile error. Multiple coils to the same operand across separate networks is permitted.
2. Branch isolation rule: a parallel branch may not feed two different coils that depend on a state variable evaluated earlier in the same network, where the same contact is intended to be both the trigger of a timer and the implicit reset of the same timer. The editor may accept the rung but the resulting scan is non-deterministic - the timer may never see a clean falling edge.

These rules are documented in the SIMATIC Programming with STEP 7 V5.5 manual, section 10.5.2. The LAD compiler flags an offending rung with a red "illegal" indicator and refuses to download the block. The fix is mechanical: split the logic into separate networks so each rung has one trigger, one timer, and one output. The IEC standard that defines these rules is IEC 61131-3 (third edition, 2013) - the older spelling "IEC 1131-3" appears in legacy literature but refers to the same standard.

Why the Parallel-Branch Blink Pattern Fails

The classic broken pattern, expressed in Micro/WIN syntax, looks like this. Do not load this on S7-300:

|     T1              T2
|----|/|------(SD)----|
|              S5T#2s
|
|     T2              T1
|----| |------(SE)----|
|              S5T#2s
|
|     T1
|----| |------( )---- M100.3

Trace one scan, assuming timer state T1 = 0, T2 = 0, M100.3 = 0:

1. Network 1: T1 NC contact is TRUE because T1 = 0. SD fires, T1 starts timing, S5T#2s loaded.
2. Network 2 (second branch): T2 NO contact is FALSE because T2 = 0. SE does not fire this scan.
3. Network 3: T1 NO contact is FALSE because T1 has not timed out yet. M100.3 remains 0.
4. Next scan, T1 is still timing (no reset). T1 NC remains TRUE. SD re-fires, restarting the 2 s every cycle. T1 never reaches its done bit. M100.3 never goes high.

The error is not the wiring - it is that the SD coil re-triggers on every cycle because the rung is always TRUE once T1 starts, and the reset path is in a different network that does not see the falling edge of T1 inside the same OB1 pass. The rung is also flagged by the IEC 1131-3 editor because the same T1 contact appears in both a trigger and a (would-be) reset role.

Clock Memory (Clock Merker) Built-In Pulses

Siemens provides periodic pulses on a configurable clock memory byte. Enable it in HW Config -> CPU Properties -> Cycle/Clock Memory, tick the "Clock memory" checkbox, and assign a byte address (typical: MB10, MB100). Each bit toggles at a fixed period with a fixed duty cycle:

Method 1 - SD + SE Two-Timer Symmetric Blink (Recommended)

Goal: M100.3 = 1 for 2 s, then 0 for 2 s, repeating. Use one SD (On-Delay) timer and one SE (Extended Pulse) timer wired in a toggle arrangement. Each network is single-purpose, IEC 61131-3 compliant, and downloads on S7-300/400 without compile errors.

Network 1 - SD timer T1

|     M100.3
|----|/|------( SD )---- T1
|              S5T#2s

T1 starts timing when M100.3 goes FALSE. After 2 s, T1.Q = 1.

Network 2 - SE timer T2

|     T1.Q
|----| |------( SE )---- T2
|              S5T#2s

When T1 finishes, T2 fires a 2 s extended pulse. T2.Q = 1 for exactly 2 s, regardless of further changes to T1.Q.

Network 3 - output M100.3

|     T2.Q
|----| |------( )---- M100.3

M100.3 = 1 while T2 is timing. When T2 expires, M100.3 goes FALSE, T1 restarts in network 1, and the cycle repeats. The toggle is clean because T1.Q and T2.Q are sequential, never simultaneous.

Timing diagram

The diagram confirms: M100.3 high from 0 to 2 s, low from 2 to 4 s, high from 4 to 6 s, low from 6 to 8 s - a symmetric 50% duty cycle at 2 s period. SD starts at 0, T1.Q rises at 2 s, T2 fires its 2 s pulse, M100.3 follows T2.Q, T2.Q falls at 4 s, M100.3 falls, T1 restarts.

Method 2 - Clock Memory Cascade for Asymmetric Pulse

If 50% duty cycle is not required, enable clock memory on MB10 in HW Config and use M10.7 (0.5 s on / 1.5 s off at 0.5 Hz) directly. To obtain a 2 s on / 2 s off without two timers, cascade a pulse timer off a 1 Hz clock bit:

Network 1:  M10.5 (1 Hz) -> ( SE T3, S5T#2s )
Network 2:  T3.Q -> output M100.3

This produces 1 s on / 1 s off, not 2 s on / 2 s off. For a true 2 s symmetric blink, use Method 1. Method 2 is useful when you need a faster heartbeat (10 Hz at M.n.0) for watchdog or communication keep-alive purposes, where a 50% duty cycle is irrelevant.

Method 3 - Single TON with Self-Reset (Legacy, Not Recommended)

It is possible to blink with a single TON by feeding its own NC contact back to its input through an SR flip-flop. The pattern is fragile because the timer must be reset by an explicit coil on a different network, and the IEC editor may flag the dual reference. Use only when timer count is constrained:

Network 1:  M100.3 NO -> ( TON T4, S5T#2s )
Network 2:  T4.Q     -> ( S M100.3 )    ; set
Network 3:  M100.3 NC -> ( R M100.3 )    ; reset
Network 4:  M100.3 NO -> ( ) M100.4      ; blink output

This works but uses four networks and one SR bit for what Method 1 does in three networks without the SR bit. S7-300 CPUs 312-314 provide 128 timers; you will not run out. Prefer Method 1.

Network Organization Rules for STEP 7 V5.5

Follow these rules to keep the LAD compiler happy on S7-300/400 and to avoid non-deterministic scan behavior:

1. One output coil per network. Multiple coils to the same operand across networks is permitted; multiple coils in the same network is a syntax error.
2. Never place a contact and its derived coil in the same network with a parallel branch that re-evaluates the same contact on the right side of the OR. The editor may accept it but the resulting scan is non-deterministic.
3. Use S5T# for time constants in LAD/FBD (for example S5T#2s, S5T#1m30s500ms). S7-300 supports the IEC TIME type T#2s in SCL only; in LAD/FBD use S5T#.
4. Treat the timer Q (done) bit as level-sensitive, not edge-sensitive. If you need an edge, generate it with a comparison or a POS edge flag in a separate network.
5. Place slow timers in OB35 (cyclic interrupt, default 100 ms period) if you want to free OB1 scan time. OB35 runs at priority class 12 by default, above OB1 (priority 1).
6. Avoid using the same timer number more than once in OB1 - the second instance is ignored. CPU 315-2 DP allows timer numbers T0 through T255 (256 total, 64 retentive).

Network Topology Diagram

The dashed feedback line is the key: M100.3 written in network 3 is read by network 1 on the next OB1 pass, not on the same pass. The SD timer sees a clean rising edge when M100.3 falls, and a clean falling edge when T1.Q rises two seconds later.

Diagnostic and Verification

After downloading the blink logic to the S7-300 CPU, verify with the online monitor (STEP 7 -> PLC -> Monitor/Modify):

1. Open OB1 in LAD/FBD and click the "Monitor" (glasses) icon. The rung should show power flow toggling between TRUE (green) and FALSE (gray) every 2 s on network 3.
2. Open a VAT (Variable Table) and create a watch for M100.3, T1, T2 with the "Modify" column set to "Pulse" or "Trigger". Set the update cycle to 500 ms for visual confirmation in the monitor.
3. Force the timer bits in the VAT to test edge cases: force T1 = TRUE, observe T2 firing and M100.3 going HIGH after 2 s, then T1 NC restarting T1 on the next scan.
4. Read the diagnostic buffer: PLC -> Diagnostic Buffer. Look for event W#16#4302 "Cycle time exceeded" if your blink logic is buried in a long FB chain and pushes the OB1 scan past the watchdog. Reduce the FB call frequency or raise the watchdog in HW Config.
5. Use the reference data (Options -> Reference Data -> Program Structure) to confirm T1 and T2 are referenced only once each in OB1. Duplicate references silently shadow.

Edge Cases and Field Caveats

Cold restart vs warm restart: timers retain their elapsed time across warm restarts (RUN -> STOP -> RUN) on S7-300 but reset on cold restart (MRES or power-up with memory reset). If you power-cycle the rack, expect the first 2 s of the blink to be "wrong" until T1 re-times out. If deterministic start-up is required, add an initial-reset network that clears M100.3, T1, and T2 on first OB1 pass after restart, detected by reading the OB100 startup bits or by comparing the restart-ob-flag byte.

Clock memory and STOP: clock memory stops when the CPU goes to STOP. The blink freezes in its last state. This is a safety feature, not a bug - do not use clock memory for safety-critical outputs (SIL 1-3). For SIL applications, derive the pulse from a hardware oscillator or a safety relay output and read it into a digital input.

OB1 scan longer than the blink period: if OB1 runs longer than 2 s, the SD timer never gets re-evaluated in the same way the source author observed. In practice, OB1 runs at 5-50 ms on S7-300 with a typical program, well under 2 s. But for OB35 cyclic interrupt blink, set the interrupt period to 100 ms or 500 ms, never 5 s, or the blink resolution collapses.

Retentive vs non-retentive: a TON/SD timer is non-retentive by default on S7-300. If you need the timer to survive a power cycle, mark it retentive in the system data (HW Config -> CPU Properties -> Retentive Memory -> Timers). Reserve retentive timers carefully - the CPU 315-2 DP has 256 timers total, 64 retentive. The CPU 314 has 128 total, 32 retentive. The CPU 312 IFM has 64 total, 16 retentive.

OB35 vs OB1 priority: a blink running in OB35 (priority 12) is not interrupted by a long OB1 scan. Use OB35 for blink that drives a safety or interlock watchdog so the blink keeps pulsing while OB1 is busy with a slow FB chain. Mind the OB35 period: a 2 s blink in a 100 ms OB35 has 20 ticks per half-cycle, plenty of resolution.

Migration to S7-1500: S7-1500 with TIA Portal accepts the same Method 1 ladder logic. S7-1500 timers are IEC 61131-3 TP / TON / TOF / TONR with nanosecond resolution; the time constant becomes T#2s instead of S5T#2s, but the three-network topology is identical. The clock memory byte works the same way; bit 7 still produces 0.5 s on / 1.5 s off at 0.5 Hz.

Cross-Platform Comparison: S7-200 vs S7-300 vs S7-1500

State Machine - Method 1 Walk-Through

S0 -> S1: T1 reaches its 2 s done bit. S1 -> S2: T2 begins its 2 s extended pulse; M100.3 set. S2 -> S3: T2 done bit falls. S3 -> S0: M100.3 NC contact in network 1 re-fires SD T1, returning to S0. The state machine has no ambiguous transitions because the trigger and reset of each timer live in separate networks, never as parallel branches in the same network.

Alternative Approaches Worth Considering

IEC TP (Pulse Timer) in SCL: on S7-300 with SCL, you can write the entire blink as a single IEC TP timer call. SCL is compiled to MC7 code; the resulting FB is functionally equivalent to Method 1 but uses one network in source and one DB in memory.

FUNCTION_BLOCK FB100
VAR
  tBlink : TP;          // IEC pulse timer instance
  bStart : BOOL := TRUE;
END_VAR
BEGIN
  tBlink(IN := bStart AND NOT tBlink.Q, PT := T#2s);
  M100.3 := tBlink.Q;
END_FUNCTION_BLOCK

Call FB100 in OB1. The blink inverts every 2 s. Note: TP does not produce a 50% duty cycle at PT = 2 s on its own - it is a single pulse of PT duration. You need to re-trigger TP by feeding its inverse back to IN. The pattern above does exactly that with bStart AND NOT tBlink.Q.

Counter-based blink: a ZV (Up Counter) driven by clock memory can also generate long-period blinks, but it adds complexity (counter preset, reset coil) for no advantage over two timers. Skip this approach.

FB call frequency reduction: if OB1 is too slow, move the blink FB into OB35 with period 100 ms. The blink state still updates every 2 s but is decoupled from OB1 scan time. Useful when OB1 runs a long recipe FB chain.

Commissioning Checklist

1. Open HW Config, open CPU Properties -> Cycle/Clock Memory, enable clock memory at MB10 (or another unused byte), confirm Save and Compile.
2. Open OB1, paste the three networks from Method 1. Save and download to the CPU (PLC -> Download).
3. Switch CPU to RUN. Open OB1 in Monitor mode. Confirm network 3 shows power flow toggling green and gray at 2 s intervals.
4. Open a VAT with M100.3, T1, T2. Set trigger to "Permanent" at 500 ms. Confirm M100.3 alternates 0/1 every 2 s.
5. Force T1 = TRUE in the VAT. Confirm T2.Q rises, M100.3 rises after 2 s, T2.Q falls, M100.3 falls, T1 restarts. Remove the force.
6. Read the diagnostic buffer. Confirm no W#16#4302 cycle-time-exceeded event. If present, raise the OB1 watchdog in HW Config by 50% and re-test.
7. Power-cycle the rack. Confirm the blink restarts from S0 on cold restart and resumes from current state on warm restart.
8. Document the timer numbers (T1, T2), the bit address (M100.3), and the time constants (S5T#2s) in the project header for the next maintainer.

Frequently Asked Questions