Programming S7-300 Warm Restart via SFB19 and OB100

Problem Overview

An S7-300 CPU can lose the ability to refresh process data on a point-to-point link (RS-232 / RS-485 / Modbus RTU master) or on a Profibus DP slave without entering the STOP operating state. The cyclic OB1 continues to scan, the diagnostic buffer records timeouts, but the loadable protocol stack (for example, the Modbus Master FB block from the PtP Communication library) does not recover by itself. Operators observe "stale" input words while the CPU still shows RUN on the SF/BF LED pair.

The symptom pattern is consistent across field reports: after the third-party controller ("slave" or "peer") misbehaves — for example, returning corrupted Modbus response frames, holding the bus line low, or simply ceasing to reply — the S7-300 user program keeps requesting data, but the receive buffer never updates. A warm restart is one accepted mitigation strategy because it re-runs OB100, re-initialises the loadable protocol stack (Modbus Master FB or FBs from the CP PtP library), and clears transient communication faults without losing the retentive data areas (M, DB, Timers/Counters with RETAIN attribute).

Two practical paths exist to trigger a warm restart programmatically from STEP 7 (Classic, V5.x) or TIA Portal:

1. Force a power-cycle of the CPU via a digital output wired through a relay — the S7-300 always performs a warm restart in OB100 after power OFF/ON.
2. Issue a remote start using SFB 19 "START" (standard library, distributed I/O section) when the target is a paired remote CPU accessible via S7 communication (BSEND/BRCV SFBs or via an integrated PN/DP interface configured for S7 connection).

Technical Foundation: S7-300 Startup Behaviour

The S7-300 family supports three startup types, evaluated by the CPU firmware each time it transitions from STOP to RUN:

The S7-300 does not support a hot restart (OB101) — only S7-400 CPUs do. Reference the official Siemens functional description for the exact behaviour matrix: Warm Restart S7-300/S7-400. The documentation explicitly states that a warm restart is performed "after a memory reset" and "after loading the user program in CPU STOP operating mode," but not as an arbitrary instruction in OB1.

Hardware Power-Cycle Method (DQ + Relay)

This is the most widely deployed field technique because it works on every S7-300 CPU (CPU 312 through CPU 319 PN/DP, firmware 2.x through 3.x) without external S7 communication partners. The principle exploits the guaranteed OB100 execution after power OFF/ON.

Wiring topology

• Allocate one free digital output (e.g., Q4.0 on a SM322 DQ32).
• Wire the DO channel through an interposing 24 V DC relay (Phoenix Contact PLC-RSC-24DC/21 or equivalent 6 A contact).
• Use the relay's normally-closed (NC) contact in series with the 24 V DC feed to the CPU's power supply module (PS 307, 5 A or 10 A).
• Fit a free-wheel diode (1N4007) across the relay coil to suppress the inductive kick on Q4.0.
• Hold the DQ OFF during normal operation; pulse it ON for the minimum CPU power-down window required by the PS module (typically 1–3 seconds for PS 307).

Inline SVG diagram of the topology:

ST code example (SCL in TIA Portal or STEP 7 Classic)

// Trigger condition: daily Modbus watchdog in DB5
// DB5.DBD0  = last good frame timestamp (DTL)
// DB5.DBX4.0 = "stale data" flag from Modbus Master FB status
// M0.0      = one-shot trigger (set by daily timer OB10)

FUNCTION_BLOCK FB100 "WarmRestartTrigger"
VAR
    tDailyRestart : TON;          // 24-hour timer
    tPowerDown : TP;              // 2.5-second pulse
    bDoCmd : BOOL;                // DO Q4.0 command
    bInRestart : BOOL;            // latch until OB100 clears it
END_VAR

BEGIN
    // Daily time-of-day interrupt (OB10) sets M100.0 once per day at 02:00
    IF "Daily_Restart_Request" THEN
        tDailyRestart(IN := TRUE, PT := T#24h);
    END_IF;

    // Modbus watchdog: if no successful exchange for >5 min, also trigger
    IF "Modbus_Stale" AND NOT bInRestart THEN
        tDailyRestart(IN := TRUE, PT := T#0s);
    END_IF;

    IF tDailyRestart.Q THEN
        tPowerDown(IN := TRUE, PT := T#2500ms);
        bInRestart := TRUE;
    END_IF;

    bDoCmd := tPowerDown.Q;
    "PS_Feed_Relay_Q" := bDoCmd;
END_FUNCTION_BLOCK

OB100 reset of the latch

// OB100 - Warm Restart (executed after power returns)
// Clear the restart latch so the next power-down requires a fresh trigger

OB100:
    "PS_Feed_Relay_Q"     := FALSE;    // release relay immediately
    "bInRestart"          := FALSE;    // clear FB100 latch
    "Daily_Restart_Request" := FALSE;   // clear OB10 trigger
    "Modbus_Stale"        := FALSE;    // clear Modbus watchdog
    tDailyRestart(IN := FALSE);
    tPowerDown(IN := FALSE);

After OB100 completes, OB1 resumes and the Modbus Master FB (for example FB7 "MB_MASTER" from the PtP library) re-initialises its request queue, the CP 341 / CP 340 / ET 200S serial module reloads its protocol buffer, and normal polling resumes.

Programmatic Method: SFB 19 / SFB 20 / SFB 21

When a second S7-300 or S7-400 CPU exists on the same Profinet/Profibus subnet with an active S7 connection, the standard library exposes three system function blocks (SFBs) for operating-state control of the partner. These are not for restarting the local CPU; they target the remote CPU reached by an established S7 connection.

All three SFBs occupy the same instance DB number range as standard SFBs (multi-instance capable). They share identical input/output topology; only the REQ mode byte differs.

Instance DB declaration (SCL)

DATA_BLOCK "DB_RemoteRestart"
    SFB 19   // START
BEGIN
END_DATA_BLOCK

Call interface (ST / SCL)

CALL "DB_RemoteRestart" , "DB_RemoteRestart"
     REQ    := bTrigger,           // rising edge initiates the restart
     ID     := W#16#1,             // S7 connection ID (NetPro/STEP 7 config)
     LADDR  := W#16#0,             // partner CPU logical address (0 = local target)
     STOP   := FALSE,              // FALSE = go to RUN (restart), TRUE = go to STOP
     MODE   := B#16#1,             // 1 = warm restart, 2 = cold restart (S7-400 only)
     RET_VAL:= iStatus,            // 0 = no error; 8xxx = warning; 7xxx = error
     BUSY   := bBusy,

END_CALL;

IF iStatus <> 0 THEN
    // Log to diagnostic buffer DB
    "Diag".ErrorCode := iStatus;
END_IF;

RET_VAL / STATUS error codes

The STOP input on SFB 19 also accepts a parameter pair (STOP = TRUE; MODE = B#16#0) to issue a STOP followed by a subsequent warm/cold restart — useful for forcing OB100 even when the remote CPU is already in RUN.

Modbus-Specific Watchdog Implementation

The original application case — communication loss with a third-party Modbus RTU controller — can also be addressed with a software-only reset of the CP 341 / CP 340 / ET 200S 1SI serial module without performing a CPU-level restart. This is preferable when the warm-restart approach is considered "brute force." Three STEP 7 components execute the reset:

1. SFC 12 D_ACT_DP — disable and re-enable the DP slave (ET 200S 1SI) which forces the Profinet/Profibus stack to re-parameterise the slave.
2. SFC 55 WR_PARM / SFC 56 WR_DPARM / SFC 57 PARM_MOD — rewrite the serial module's dynamic parameters (baud, parity, Modbus timeout) to clear the protocol FSM.
3. Re-init of the Modbus Master FB instance — call FB "MB_MASTER" with INIT = TRUE for one scan, then FALSE.

SCL example: DP slave disable/enable cycle

// Reset ET 200S 1SI on Profibus DP, slave address 7
IF "Modbus_Stale" AND NOT "Reset_In_Progress" THEN
    "Reset_In_Progress" := TRUE;
    iStatus := D_ACT_DP(
        REQ     := TRUE,
        MODE    := 0,             // 0 = deactivate
        LADDR   := W#16#7,        // DP slave diagnostic address
        RET_VAL := iRet);
    // After 2 s delay, re-activate
    tResetCycle(IN := TRUE, PT := T#2s);
    IF tResetCycle.Q THEN
        iStatus := D_ACT_DP(
            REQ     := TRUE,
            MODE    := 1,         // 1 = activate
            LADDR   := W#16#7,
            RET_VAL := iRet);
        "Reset_In_Progress" := FALSE;
        "Modbus_Stale"      := FALSE;
    END_IF;
END_IF;

This approach keeps the S7-300 in RUN, retains all DBs, and resolves the same stuck-Modbus-stack symptom in roughly 3–5 seconds without operator intervention. Use the power-cycle warm-restart only when the DP-slave reset does not recover the link.

Commissioning and Verification

Verify each restart method end-to-end before deploying to production. The following checklist covers the hardware relay path; the SFB 19 path uses the same verification steps with a remote CPU in place of the local relay.

1. Connect STEP 7 (V5.5/V5.6 or TIA V16–V18) online to the CPU. Open "CPU → Operating Mode." Note current mode = RUN, scan cycle time, and diagnostic buffer events 1–10.
2. Force the trigger bit (M100.0 for daily timer, or set DB5.DBX4.0 manually to simulate the Modbus watchdog).
3. Watch Q4.0 transition to TRUE on the online monitor. Measure the relay pulse duration with a handheld scope or the SM322 channel-status monitor: expected 2500 ms ±50 ms.
4. Confirm the PS 307 output voltage drops to 0 V for at least 100 ms during the pulse — required for the CPU's voltage monitoring (V_monitor) to register a power fail and queue OB100 execution.
5. When power returns, observe that the CPU executes OB100. Verify in the diagnostic buffer: Event ID 0x4905 "Restart (warm) executed."
6. Confirm OB1 resumes at the last executed network and that all non-retentive M/PIQ are zero. All RETAIN-marked M, DB, T, C retain last values.
7. Monitor the Modbus request/response counters in the PtP FB status word. The first frame after restart should receive a successful reply within the configured response timeout (default 2000 ms for FB7 "MB_MASTER").
8. Disconnect the third-party controller and verify the daily timer still triggers a restart (so the procedure is proven even when the recovery is not needed).

Safety and Operational Caveats

Diagnostic Buffer Reference Events

Read the diagnostic buffer with STEP 7 → PLC → Module Information → Diagnostic Buffer. Filter on ID = 0x4905 to confirm a warm restart was the most recent transition.

Parameter Summary Table

Troubleshooting Matrix

FAQ