S7-300 PLC STOP on PROFINET Startup: Resolving OB86 Rack Failure

1. Problem Overview

An S7-300 PLC acting as a PROFINET IO controller enters the STOP state at startup when a configured PROFINET IO device is not yet reachable. The diagnostic buffer logs a rack failure caused by the missing IO device and stops the CPU with the entry "OB not loaded or not possible, or no FRB". The symptom is most visible on machines where one or more IO devices (robots, drives, vision systems, third-party controllers) take significantly longer to boot than the S7-300 CPU.

This article documents the specific failure mode observed on an ET 200S station built around an IM151-8 PN/DP CPU (Siemens article number 6ES7151-8AB00-0AB0 for firmware V2.x, 6ES7151-8AB01-0AB0 for firmware V3.x). The IO controller is connected to a KUKA robot controller (KR C4) that requires roughly two minutes to complete its own boot. The IM151-8 CPU finishes power-on in about 20–40 seconds, polls the IO device, receives no response, and goes into STOP because the project does not contain an OB86 (Rack Failure OB).

The fix is to create OB86 in the STEP 7 project. The block can be empty; the CPU only needs the block to exist so the operating system has somewhere to deliver the rack-failure event. After downloading the new OB86, the CPU remains in RUN while the IO device is offline, and resumes cyclic IO exchange as soon as the IO device returns.

2. Affected Hardware and Firmware

Identify the exact components before applying any fix. The failure mode is the same for all S7-300/ET 200S CPUs that act as a PROFINET IO controller (CPU 315-2 PN/DP, CPU 317-2 PN/DP, CPU 319-3 PN/DP, and the IM151-8 PN/DP CPU), but the configuration steps differ slightly between STEP 7 V5.x and TIA Portal.

Verify the firmware version of the IM151-8 in PLC > Module Information > Online > Firmware or read it from the physical module's label. Firmware V3.x is recommended because it adds the "IO device is not required for CPU startup" configuration option in HW Config, which is a much cleaner solution than relying solely on OB86.

3. Diagnostic Buffer Interpretation

The diagnostic buffer is the most reliable source of root-cause information. Open SIMATIC Manager > PLC > Module Information > Diagnostic Buffer (STEP 7 V5.x) or Online & Diagnostics > Diagnostics buffer (TIA Portal). The events that prove the missing-OB86 root cause appear in the following sequence:

The detail line for the station-failure event includes the following parameters, taken directly from a real IM151-8 buffer in this configuration:

• Address of affected station (input): 2042 — logical base address of the IO device input area
• IO system ID: 100 — PROFINET IO system index 100 (the first PN IO system in the CPU)
• Station number: 1 — PROFINET device number assigned in HW Config
• Logical base address of the IO controller: 2043 — controller's interface slot
• Requester OB: RACK failure OB (OB86)
• Priority class: 26 — OB86 runs at priority 26 in the S7-300/ET 200S
• Event class: External error, outgoing event

Translate hex event ID 16#38CB to the OB86 form: FLT_ID = B#16#0B with EV_CLASS = B#16#38 (outgoing = station return). For comparison, the failure event decodes as FLT_ID = B#16#0A with EV_CLASS = B#16#39 (incoming = station failure). The full set of OB86 PROFINET FLT_ID values used by the IM151-8 / S7-300 PN CPUs is:

4. Root Cause Analysis

The S7-300 and ET 200S CPUs follow a fixed startup sequence defined in the operating system:

1. Power-on or mode selector transition from STOP to RUN.
2. Hardware configuration is evaluated; configured PROFINET IO devices are polled within the IO startup timeout.
3. OB100 (warm restart) is executed once, top to bottom.
4. Cyclic operation begins: OB1 runs, the IO controller cyclically updates IO devices, and PROFINET alarms are dispatched to OB82/OB86.

If a PROFINET IO device is not accessible during step 2, the operating system raises a rack failure event. The expected user response is to load OB86 in the project. The CPU then calls OB86 with the relevant OB86_MDL_ADDR, OB86_FLT_ID, and OB86_PNT_INFO values. If OB86 is not loaded, the CPU cannot pass the failure event to a user program and, by design, transitions to STOP with the diagnostic buffer entry "OB not loaded or not possible, or no FRB".

This is the documented default behaviour in the S7-300 CPU 31x system manual and the IM151-8 PN/DP CPU operating instructions. A useful reference for the failure pattern is the Siemens TIA Portal manual collection, which describes how an IO device failure is handled in the S7-1500R/H redundant system: Failure of an IO device in the PROFINET ring. The S7-300/ET 200S follow the same conceptual model, although the configuration options are more limited.

5. Primary Solution: Create OB86 in STEP 7 V5.5

The most direct fix is to insert an OB86 organisation block into the S7 program. An empty OB86 is sufficient — the CPU only needs the block to exist so the operating system has somewhere to deliver the rack-failure event.

5.1 Procedure in STEP 7 V5.5 (SIMATIC Manager)

1. Open SIMATIC Manager and load the S7-300 / ET 200S station from the project archive.
2. In the project tree, expand S7-300 CPU > S7 Program > Blocks (for STEP 7 V5.x) or CPU > Program in TIA Portal.
3. Right-click Blocks > Insert New Object > Organisation Block.
4. In the Properties — Organisation Block dialog, set the following values:
   • Name: OB86
   • Symbolic name: Rack_Failure (optional but recommended for readability)
   • Author: project default
   • Comment: Handles PROFINET IO device failure and return; prevents CPU STOP on rack failure
5. Click OK. STEP 7 generates a default OB86 with the standard local variable declarations (OB86_EV_CLASS, OB86_FLT_ID, OB86_IO_FLAG, OB86_MDL_ADDR, OB86_RACKS_FLTD, OB86_PNT_INFO, OB86_Z2).
6. Do not add any user code. The default contents (a single BE instruction) are sufficient for the CPU to remain in RUN.
7. Save and compile the program (Station > Save and Compile or Ctrl+F7).
8. Download the blocks to the CPU (PLC > Download or Ctrl+L). The online dialog will warn that the CPU will be stopped for the download. The IM151-8 then performs an automatic warm restart after the download.

5.2 Procedure in TIA Portal

1. Open the project in TIA Portal (V13 SP1 or later, V15.1+ recommended for IM151-8 V3.x firmware).
2. Expand the S7-300 / ET 200S station in the project tree.
3. Right-click Program blocks > Add new block.
4. Choose Organisation block as the type, set the name to OB86, and confirm the number 86.
5. Click OK. TIA Portal inserts a default OB86 with the same local variable declarations as STEP 7 V5.x.
6. Compile the program and download the blocks to the CPU.

6. Secondary Solution: Configure PROFINET IO Startup Behaviour

For a more deterministic configuration, adjust the PROFINET IO device startup parameters in HW Config. This complements OB86 and reduces the number of rack-failure events that the application has to handle.

1. Open the S7-300 / ET 200S station in HW Config (STEP 7 V5.x) or in the device view (TIA Portal).
2. Select the PROFINET IO interface of the IM151-8 CPU.
3. Open Properties > PROFINET IO > Startup (TIA Portal: Properties > General > PROFINET interface > Advanced options > Startup).
4. Set "Compare preset / actual configuration" to "Startup CPU only if expected configuration matches" only when every IO device must be present at startup. For mixed-criticality installations, leave this option disabled.
5. Open the properties of the IO device (KUKA controller). Set the Watchdog time and the Replacement time to values that tolerate the robot's two-minute startup. A typical value for a 2-minute boot is 200,000 ms (200 s) for both fields.
6. In the PROFINET interface properties of the CPU, on the Time tab, set the IO device startup timeout to a value larger than the worst-case IO device boot time.

Firmware V3.x of the IM151-8 PN/DP CPU adds the option "IO device is not required for CPU startup" in the PROFINET IO device properties (HW Config / device view). When this checkbox is enabled, the IO controller does not stall startup if the device is missing, and the CPU enters RUN immediately. Enable this option when the IO device is a non-critical peripheral (robot, vision, or auxiliary drive) and when the application can tolerate the IO device being absent during the first scan cycles.

7. Supplementary OBs for Startup Behaviour

OB86 is the minimum required block. Three other OBs frequently improve startup behaviour in this exact scenario and should be added to every S7-300 / ET 200S PROFINET deployment as a baseline.

For a robust deployment, insert all four OBs as empty blocks. The CPU then ignores these errors and continues in RUN. Add real user code to OB82/OB86/OB122 only when you need to log the events or set fallback values for the application.

7.1 Example: initialise a startup handshake in OB100

Insert the following STL snippet into OB100 to set a startup-completed flag that the HMI can poll. Replace the operand names with the symbols used in your project.

      A     "HMI_Heartbeat"          // HMI heartbeat tag (M100.0)
      AN    "CPU_Restart_Lock"       // Latch cleared on operator reset (M100.4)
      S     "CPU_Startup_Done"       // Set startup flag (M100.1)
      S     "Robot_Online_Required"  // Set robot-expected flag (M100.2)
      R     "Robot_Online_OK"        // Clear robot-online flag (M100.3)
      R     "PN_IO_Station_Fault"    // Clear sticky PROFINET fault (M100.5)
      BEA                            // End of OB100 (warm restart)

7.2 Example: log OB86 PROFINET IO failure in SCL

Insert the following SCL block in OB86 to copy the failure code into a flag word that the HMI can display. The block leaves the CPU in RUN by simply ending with RETURN — no special action is required.

// SCL source for OB86
IF #OB86_IO_FLAG = B#16#54 THEN
   // PROFINET IO failure (FLT_ID 0x0A or 0x0C)
   "PN_IO_Fault_Code" := WORD#16#0A00 + #OB86_FLT_ID;
   "PN_IO_Fault_Addr" := #OB86_MDL_ADDR;
   "PN_IO_Station_Nr" := #OB86_Z2;
   "PN_IO_Station_Fault" := TRUE;
ELSE
   // PROFINET IO return (FLT_ID 0x0B or 0x0D)
   "PN_IO_Station_Fault" := FALSE;
   "PN_IO_Return_Code" := WORD#16#0B00 + #OB86_FLT_ID;
END_IF;
RETURN;

8. Warm Restart Without STEP 7

The original problem statement requires a way to bring the CPU out of STOP without STEP 7 once the HMI is in charge of the line. Several mechanisms are available; choose the one that matches the operational constraints of the machine.

8.1 Mode selector switch

The IM151-8 PN/DP CPU has a three-position mode selector on the front:

• RUN — CPU executes the user program in cyclic mode.
• STOP — CPU is stopped, outputs are disabled, diagnostic buffer is preserved.
• MRES — memory reset (not needed for a warm restart).

Toggle the switch from STOP → RUN to perform a warm restart. The outputs are re-initialised according to the values in OB100, OB100 runs once, and the CPU returns to RUN. This is the most reliable field-tested method but requires physical access to the PLC.

8.2 Power cycle

Power the CPU off, wait at least 3 seconds, then power it back on. The CPU performs a warm restart as long as the operating mode is set to RUN on the selector and the retentive memory is configured correctly. A cold restart (OB102) only occurs if the power-on is treated as a cold restart by the CPU configuration; on the IM151-8 with a valid OB100 in the project, the power-on is treated as a warm restart by default.

8.3 Restart from a custom HMI via S7 communication

When the HMI is the only available tool, send an S7 "START" command to the CPU. Three options are available, depending on the HMI driver:

1. Built-in driver function: most modern SCADA packages (WinCC / TIA WinCC, Zenon, iFIX, InTouch, Citect) include a PLC start/stop command. Enable the option in the driver configuration and bind it to a button on the HMI screen.
2. PG/PC S7 protocol: use the SIMATIC Automation Tool (Siemens) or a custom .NET application that connects via TCP/IP to the CPU's PROFINET interface and sends a START command. The CPU accepts a START command from a partner with PG (programming) rights; configure the connection in NetPro / "Devices & Networks" with the right PG authorisation.
3. Soft-PLC handshake: a user program in OB1 monitors a control bit (e.g. M 200.0 = Request_Restart) that the HMI sets. When the bit is detected, the program calls SFC46 "STP" to put the CPU in STOP. After a configurable delay, the HMI sends the START command, and OB100 re-initialises the application.

For a fully autonomous HMI-driven restart, configure the S7 connection with PG rights on the HMI side. The CPU accepts a START command from a partner whose "Connection resource" is configured as "PG/OP connection" and whose "Connection authorisation" includes the "Start" right. In NetPro / TIA Portal Devices & Networks, open the S7 connection properties and set Connection authorisation to PG/OP.

8.4 Soft warm restart via SFC20 / SFC46

For an HMI-driven restart that does not require the S7 START command, implement a "soft warm restart" sequence:

1. The HMI sets the control bit Request_Restart (e.g. M 200.0).
2. OB1 detects the bit and calls SFC46 "STP" to put the CPU in STOP.
3. The HMI detects the STOP (via the diagnostic buffer or a status tag read cyclically) and, after a configurable delay, toggles a digital output connected to a relay that momentarily powers the CPU off and on.
4. On power-on, the CPU performs a warm restart and runs OB100, which clears the Request_Restart bit and signals completion to the HMI.

9. Advanced Diagnostics with SFC/SFB

When the basic OB86 approach is in place, add diagnostics in the user program to log IO device state transitions. The following blocks are useful:

Example — read PROFINET IO system status in OB1 cyclically and store the device state in a flag byte:

// Call SFC51 to read SSL 0x00B4 (PROFINET IO status)
CALL  "RDSYSST"          // SFC51
     REQ     := TRUE
     SZL_ID  := W#16#00B4
     INDEX   := W#16#0001
     RET_VAL := "SFC51_RetVal"           // INT return code
     BUSY    := "SFC51_Busy"             // BOOL busy flag
     SZL_HEADER := "SFC51_Header"        // 32-byte SSL header
     DR      := "PN_IO_Status_Buffer"    // 28-byte data record per IO system

SSL 0x00B4 returns a 28-byte record for each PROFINET IO system. Byte 0 contains the IO system state, byte 1 the number of IO devices, and the remaining bytes list the IO device number, the number of slots, and the number of submodules per device. Other useful SSL IDs for IO diagnostics on the IM151-8 / S7-300 PN CPU are:

10. Verification Procedure

Run the following procedure after the OB86 has been downloaded to confirm the fix. Repeat the test at least three times to confirm repeatability, and document the diagnostic buffer and LED states for the operator manual.

1. Power-cycle the IM151-8 CPU while the KUKA robot controller remains off.
2. Wait for the CPU to finish startup (about 20–40 s for IM151-8 V3.x).
3. Open Module Information > Diagnostic Buffer:
   • Confirm event #1 is PROFINET IO: station failure with FLT_ID B#16#0A.
   • Confirm there is no STOP caused by rack failure entry.
   • Confirm OB86 was called (event class External error, incoming with OB86 reference).
4. Confirm the CPU mode is RUN: the mode selector and the online view both show RUN, the RUN LED on the front is steady green, and the STOP LED is off.
5. Power on the KUKA robot controller and wait for it to finish startup.
6. After the controller is online, observe a new diagnostic buffer entry: PROFINET IO: station return, event 16#38CB with FLT_ID B#16#0B.
7. Verify cyclic IO exchange by toggling a digital output on the KUKA controller and observing the corresponding input in the S7 program (use a VAT table in STEP 7 or a tag in the HMI).
8. Repeat the test three times to confirm repeatability. Document the diagnostic buffer screenshot, the LED states, and the timestamps in the commissioning report.

A correct implementation keeps the RUN LED steady throughout, even with the BF LED on during the KUKA controller's boot phase. The BF LED will turn off as soon as the IO device returns and starts cyclic data exchange.

11. Field-Proven Best Practices

• Always include OB82, OB86, OB100, OB122 as a baseline in any S7-300/ET 200S deployment that uses PROFINET IO with non-deterministic slaves. Empty blocks are acceptable. This single rule prevents the majority of unexpected STOP events on production machines.
• Configure PROFINET IO timeouts in HW Config to be larger than the worst-case slave boot time. For a 2-minute KUKA boot, set the IO device Replacement time to 200,000 ms (200 s) and the Watchdog to the same value.
• Use OB100 to initialise HMI tags, set first-cycle flags, and clear latched alarms. This makes the cold/warm restart behaviour deterministic and the HMI display predictable.
• Avoid direct I/O access to PROFINET inputs that may be unavailable. Use the process image (PII/PIQ) and let OB122 handle access errors. Prefer the "All" process image update setting in HW Config.
• Use a dedicated "Restart Lock" bit in OB86. If the application requires operator acknowledgement after a fault, set a sticky error bit in OB86 that the HMI must clear before allowing a restart. This prevents the machine from cycling in and out of faults without operator intervention.
• Document the LED behaviour for the operators so they can distinguish a normal "BF during slave boot" from a true bus fault. A small label on the cabinet door is often the most cost-effective documentation.
• Keep STEP 7 and the project archive on the HMI PC or a versioned file server. Even if STEP 7 is no longer in use for online commissioning, a copy is needed if a memory reset is ever required. The project archive is the single source of truth for the system configuration.
• Validate the restart path under controlled conditions before relying on it. The HMI-driven restart requires a working S7 connection; if the CPU is in STOP and the HMI is the only partner, the HMI must have the correct PG/PC interface configuration and connection rights.
• Use a watchdog bit in the HMI that toggles cyclically and is monitored by the S7 program. If the HMI goes off-line, the S7 program can detect the loss of the watchdog and enter a safe state.
• Test the OB86 fix with multiple slaves. The fix is independent of the number of IO devices; each device triggers OB86 individually with its own station number. Verify that all slaves are handled correctly when they come online at different times.

FAQ