Configuring S7-300/S7-400 Startup OBs OB100, OB101, OB102

Overview of S7-300/S7-400 Startup Organization Blocks

Startup organization blocks (OB100, OB101, OB102) are executed exactly once during the transition of a Siemens SIMATIC S7-300 or S7-400 CPU from STOP to RUN. They are not part of the cyclic scan; they are called once by the operating system immediately before OB1 takes over, and the start information is supplied in the OB's local data (TEMP area). After the startup OB completes, normal cyclic execution begins. Code placed in OB100, OB101, or OB102 therefore represents a one-shot, deterministic initialization phase that runs before any scan of the user program.

Three restart behaviors are defined in the SIMATIC firmware, each with its own organization block:

• OB100 – Complete restart (warm restart): default restart for S7-300 and S7-400 when the CPU is switched from STOP to RUN or after power-off/power-on with a backup battery retaining memory.
• OB101 – Hot restart: only supported on S7-400 (and S7-400H). The program resumes at the point of interruption as if nothing happened; all dynamic data is preserved.
• OB102 – Cold restart: only supported on selected S7-400 CPUs. The program starts with the initial values from the load memory; all retentive flags, DB contents, timers, and counters are cleared.

For a complete description in the current documentation set, see the Siemens manual Startup organization blocks (OB 100, OB 101 and OB 102) – TIA Portal V21.

Restart Type Comparison

OB100 — Complete Restart (Warm Restart)

OB100 is the only startup OB that exists on every S7-300 and S7-400 CPU. It runs when the CPU transitions to RUN after any of these events:

• CPU mode selector moved from STOP to RUN or RUN-P.
• Power off / power on with battery-backed RAM retained (warm restart).
• PG command PLC → Cold Restart / Complete Restart from STEP 7 or TIA Portal.
• Self-initialization after a programming/download operation.

Typical content for OB100:

• Reset non-retentive machine flags.
• Initialize the first-scan bit pattern.
• Pre-load recipe data from a DB.
• Bring drives to a defined reference state.
• Set or clear specific outputs in the process image.

Reading OB100 start information

OB100 receives 20 bytes of local data populated by the operating system. The most-used fields are OB100_EV_CLASS (event class, typically B#16#13), OB100_STRT_INFO (restart cause), and OB100_PRIORITY (priority class 27 on most CPUs). In SCL/ST you can read them as local TEMP variables of type BYTE/WORD.

OB101 — Hot Restart (S7-400 only)

OB101 is only available on S7-400 (and S7-400H) CPUs. It allows the program to resume execution at the exact instruction pointer where the power failure occurred, without losing any dynamic state — provided the backup battery preserved the work memory and the power dip was within the CPU's buffer time. This is the closest behavior to a true "continue where you left off" mode that S7-400 offers.

OB101 must be enabled in the CPU's hardware configuration under Properties → Startup. The setting Hot restart determines whether the firmware attempts a hot restart or falls back to a complete restart (OB100) if conditions are not met.

OB102 — Cold Restart (S7-400 only)

OB102 is supported on the older S7-400 CPU families (CPU 4x3 / 4x5 / 4x7). It forces the CPU to load all data blocks and flags from their initial values, exactly as if the program had just been downloaded. OB102 is enabled from the mode selector or from STEP 7 / TIA Portal with a Cold restart command. It is rarely used in continuous process plants because it wipes recipe and production data; it is more typical of machine building where every shift starts from a defined clean state.

Newer S7-400 CPUs (CPU 410, CPU 416F, the SIPLUS variants) and every S7-300 do not implement OB102 at all. Calling OB102 on an unsupported CPU raises an OB not loaded fault and the CPU remains in STOP.

CPU Compatibility Matrix

Programming OB100 in STEP 7 Classic (LAD / FBD / STL)

To create a startup OB in STEP 7 V5.x:

1. Open the S7 project in SIMATIC Manager.
2. Right-click the Blocks container in the S7 program.
3. Choose Insert New Object → Organization Block.
4. In the dialog, change the default OB number from 1 to 100, 101, or 102.
5. Open the new block, add a network, and write the initialization code.

Minimal STL example in OB100 that sets flag M10.0 on first scan:

// OB100 — Complete Restart
SET
= M10.0           // FirstScan_CompleteRestart
L 0
T MW12            // Clear a scratch word
SET
= M10.1           // Optional: drive ready-to-run latch
BE

Every time the CPU executes a complete restart, M10.0 will go TRUE. Because M10.0 is retentive, the bit survives a power dip and can be checked in OB1 by reading its current value. To get a true one-shot in OB1 on each restart, place a one-shot logic in OB1 that detects the rising edge of M10.0 together with the falling edge of OB1_prev_run.

Programming OB100 in TIA Portal (SCL)

In TIA Portal (V16 and newer, including V21) the procedure is identical for the project tree:

1. Expand the PLC device folder → Program blocks.
2. Double-click Add new block.
3. Choose type Organization block, name it OB_Startup (or keep default).
4. Set the OB number to 100 manually in the block properties.
5. Edit the block in LAD, FBD, or SCL.

SCL example for OB100 that initializes recipe parameters and a few machine flags:

// OB_Startup (OB100) — Complete Restart, SCL
IF "FirstScan" THEN           // FirstScan is a system-side flag in S7-1500; on S7-300 use a manual bit
  RETURN;
END_IF;

// Reset non-retentive state
"Machine".StepNumber := 0;
"Machine".FaultWord  := 0;
"Machine".CycleCount := 0;

// Initialize recipe pointer
"Recipe".ActiveID := 0;

// Set outputs in process image to safe default
"DO_ConveyorStart" := FALSE;
"DO_HeaterEnable"  := FALSE;

// Latch the one-shot flag
"FirstScan" := TRUE;

For the current Siemens documentation, see Startup organization blocks (OB 100, OB 101 and OB 102).

Reading the Startup Information Bytes

All three startup OBs receive 20 bytes of standardized start information in their TEMP area. The fields of practical interest in S7-300/S7-400 are:

Use these fields to log or display the precise reason for a startup in your HMI, which is invaluable when a process line trips overnight and the on-shift engineer needs to know whether it was a manual stop, a watchdog, or a power event.

Process Resumption After Power Loss — Picking the Right OB

The recurring field question is: "My line lost power; which OB makes the process continue where it stopped?"

• If the CPU is an S7-300: you only have OB100. The CPU will complete-restart, which means timers/counters/non-retentive flags are reset but the program is intact. You must design the application to either: (a) save its current state to retentive DBs periodically and reload them in OB100, or (b) treat every cold power-on as a manual restart and require an operator to resume the line.
• If the CPU is an S7-400 with hot restart enabled (OB101): the firmware restores all dynamic state and resumes the OB1 instruction pointer automatically. You still need OB100 for a clean manual stop-start, but OB101 handles unplanned power dips below the backup time window.
• OB102 is the wrong choice for resume-after-power-failure; it deliberately throws away state.

A robust "resume where we left off" pattern on S7-300 is to write the critical state (current step, position, recipe index) to a retentive DB every scan, then read that DB back in OB100 and force the matching outputs before OB1 starts. The OB100 + OB1 split guarantees deterministic behavior on every power-up.

Practical Patterns for OB100

1. First-Scan Latch

// OB100
SET
= M 10.0          // FirstScan_OB100

Use FP M10.0 in OB1 if you need a single one-shot edge per restart. Because M10.0 is retentive, it survives across restarts, so a true one-shot must use an edge detector each scan.

2. Default Output Image

// OB100 — write safe defaults to the process image
L 0
T QB 0            // Byte 0 outputs to 0
L 0
T QB 4            // Byte 4 outputs to 0

This is essential for safety: with OB100 absent or empty, the process image outputs are zero on every restart, which can cause unexpected movement if your application relied on outputs being latched from the previous run.

3. Drive Pre-Charge

Many SINAMICS G/S drives expect a control word handshake in the right order at startup. OB100 is the right place to set STW1 to the defined pre-charge pattern (e.g. W#16#047E) before the cyclic OB1 takes over the velocity ramp.

4. Recipe Load

On restart, copy the active recipe from the retentive "shadow" DB to the working DB:

CALL FB 100, DB100  // Copy_Recipe_Shadow_To_Working

Diagnostics: What to Look at When Startup Fails

If the CPU does not reach RUN after a power-on, the most common causes involving OB100/101/102 are:

Commissioning Procedure for Startup OBs

1. Open the CPU's Device view in TIA Portal and confirm the configured Startup behavior (e.g. Complete restart).
2. Insert OB100 in the project, even if empty, so the CPU does not fault on OB not loaded.
3. Add your initialization logic and compile. Watch the Compile log for unused tags and overlapping TEMP variables.
4. Download in STOP first to force a complete restart and verify the OB100 path.
5. From the online Diagnostics → Diagnostic buffer, confirm that the most recent entry shows Complete restart triggered by … and the start time matches.
6. Force a power-off / power-on test. Check the SF / BF / DC5V LEDs, the diagnostic buffer, and the values in your retentive DBs.
7. For S7-400 with hot restart enabled, perform a controlled power dip (e.g. < 1 s) and confirm the CPU returns via OB101 with retained state.
8. Document the expected output state for the first OB1 scan in your functional specification so that operators know what to expect on every restart.

Common Pitfalls

• Confusing scan order: OB100 runs before OB1, not in parallel. Do not place logic in OB1 that depends on OB100 having set a flag in the same scan — it does, but only on the first cycle. Subsequent cycles start with OB1 alone.
• Heavy work in startup OB: anything that takes more than a few seconds (e.g. FTP transfers, slow I/O) can trigger the OB watchdog and drop the CPU into STOP.
• Forgetting OB100 in a new project: on a S7-300 the CPU still starts even without OB100, but no user initialization is executed. Many plants run with empty OB100 for years until they add a recipe or a drive and discover that outputs are not in the expected state.
• Re-downloading with retentivity set to false: STEP 7 / TIA Portal can reset the Retentivity property of DBs if you change the block interface. This is the most common reason an "OB100 that used to work" suddenly loses the resume-from-state behavior.
• OB100 not present in the offline/online diff: during partial downloads, OB100 can be skipped if its timestamp matches but the rest of the program has changed. Always do a full download before commissioning a startup sequence.

Quick Reference: When to Use Which OB

FAQ