Configuring S7 Error OBs to Prevent CPU STOP on Hardware Faults

On Siemens S7-300, S7-400, S7-1200, and S7-1500 controllers, every detected runtime fault is routed by the operating system to a dedicated Organization Block (OB). If the corresponding OB is not present in the user program, the CPU escalates the event and transitions to STOP. The standard engineering response is therefore to download the appropriate Error OB into the load memory. An empty OB is sufficient to suppress the STOP transition; a programmed OB lets you react to the event, log it, or fail over to a safe state.

This reference covers the full family of S7 Error OBs, the priority classes that govern their execution, the STEP 7 V5.x and TIA Portal procedures for adding them, and the diagnostic information the OBs make available. It also addresses the common field case where an engineer removes or swaps a distributed I/O module during commissioning and watches the CPU drop into STOP because OB83 / OB86 have not been loaded.

1. Why an Unhandled Error Drives the S7 CPU to STOP

The S7 CPU operating system executes a deterministic scan cycle. When a fault is detected during I/O update, communication processing, or program execution, the OS queries the OB registry for the matching error OB:

1. The fault is classified into one of the OB80–OB87 (synchronous/asynchronous hardware errors) or OB121/OB122 (program execution errors) categories.
2. If the matching OB exists in the load memory, it is started according to its priority class. The main cyclic OB (OB1) is paused for the duration of the error OB.
3. If the matching OB is not present, the OS calls the OB102 (cold restart) / OB88 / OB121 / OB122 / OB80 fault routine depending on firmware, and finally transitions the CPU to STOP. The SF (System Fault) LED turns on, and the diagnostic buffer records the entry “STOP due to missing OB” with the OB number.

Loading the OB into the load memory is therefore a hard requirement for continued operation. The OB does not need to contain any code; an empty body satisfies the OS and the CPU remains in RUN.

2. The S7 Error OB Family at a Glance

The following table consolidates every standard error OB across the S7-300/400 and S7-1200/1500 lines. Some entries apply only to certain CPU series; this is called out in the “Applicable platforms” column.

3. Priority Classes and OB Execution Order

The priority class determines whether an error OB can interrupt the currently executing OB. The table below shows how priority is assigned in firmware V4.x for S7-300/400 and V2.x for S7-1500. Newer firmware revisions expose the priorities in the OB properties dialog.

The local data stack is shared across all OBs in a priority class. If an error OB is allocated 256 bytes by default but the code uses more, the stack will overflow and OB85 (priority class error) will be raised. When writing a diagnostic-heavy OB82, raise the local data allocation in the OB properties (STEP 7) or in the OB’s “Properties > General > Local Data Stack” tab (TIA Portal).

4. Prerequisites Before Adding an Error OB

Before loading an error OB, confirm the following items. Each one is a separate failure mode that produces confusing symptoms if missed.

• Project match. The offline project must match the online CPU firmware. Mismatched firmware versions on S7-1500 generate a download rejection with error code “Online/offline difference”.
• User rights. The PG/PC must have the project password or the CPU must be in a state that allows program changes. Without rights, the online OB cannot be loaded.
• CPU mode. To load a new OB during commissioning, the CPU must be in STOP or in “RUN with test…program changes” (S7-300/400) / “RUN with extended program modifications” (S7-1500 with firmware V2.6 or later).
• Available load memory. Each empty OB occupies roughly 200–400 bytes of load memory. S7-300 CPUs with a 64 KB MMC will refuse a download that exceeds free memory.
• Hot-swap capable hardware. If the goal is to prevent STOP on module removal, the rack or station must physically support hot swapping. Standard S7-300 IM153 does not; ET 200S, ET 200M with active backplane, and ET 200SP do.

5. Step-by-Step: Adding an Empty Error OB in STEP 7 V5.x (S7-300/400)

The classic SIMATIC Manager workflow for adding an error OB to a STEP 7 V5.x project is shown below. The same logic applies to S7-300 and S7-400.

1. Open the project and expand the S7 program node in the project tree.
2. Right-click Blocks and select Insert New Object > Organization Block (OB).
3. In the “Properties – Organization Block” dialog, set the symbolic name and click the dropdown under “OB”. The list shows all OBs valid for the selected CPU; the fault interrupts are grouped at the bottom.
4. Select OB82 (Diagnostic Interrupt) for a module fault, OB83 for module removal, OB86 for station failure, and so on.
5. Accept the default priority, leave the body empty, and click OK.
6. Repeat for every OB that the application might trigger. A minimum recommended set is OB80, OB82, OB85, OB86, OB121, OB122.
7. Select all OBs in the block folder, right-click, and choose Download. Confirm the target module selection. The CPU will accept the new blocks in RUN (with the “Test…Program changes” option on S7-400) or require a STOP transition for S7-300.
8. Open PLC > Diagnostic/Setting > Module Information and verify the OBs are present under the “Block Folder” tab. The diagnostic buffer should now record event class “OB Start” entries instead of STOP transitions when the corresponding fault occurs.

6. Step-by-Step: Adding an Error OB in TIA Portal (S7-1200/1500)

The TIA Portal workflow exposes every OB through the “Add new block” dialog. The procedure below has been validated on TIA Portal V17 and V18 with S7-1500 CPUs running firmware V2.9.

1. Open the project and expand PLC_x > Program blocks in the project tree.
2. Double-click Add new block.
3. In the dialog, choose the Organization block category and use the search filter to type “Error” or scroll to the fault interrupt section.
4. Select the desired OB number (OB82, OB83, OB86, etc.). TIA Portal automatically pre-fills the symbolic name and the language (LAD/FBD/SCL/STL are all supported; SCL is recommended for diagnostic bodies).
5. Click OK. The OB editor opens with the standard interface declarations already populated (Temp variables for the start info).
6. Optionally add code. The minimum body that satisfies the OS is empty.
7. Compile the project (Project tree > right-click CPU > Compile > Software).
8. Download to the device (Online > Download to device). On S7-1500 with firmware V2.6 or later, the download can occur in RUN through the “Download to device” wizard if the OB does not modify the same data blocks currently being read by OB1.
9. Open Online > Online & Diagnostics > Diagnostics buffer and verify the new event class entries “OB82 START” / “OB86 START” appear after a forced fault.

The TIA Portal adds two features that are not present in STEP 7 V5.x: the OB’s start info is automatically decoded into named temporary variables (for example OB86_FLT_IOID), and the diagnostic event is integrated with the ProDiag fault model introduced in TIA V15.1. If ProDiag is enabled, the same OB82 instance can be reused across multiple supervised blocks.

7. Empty OB vs Programmed OB: Choosing the Right Strategy

Loading an empty OB is the minimum acceptable response for a non-safety machine that must keep cycling while maintenance is performed. It is not, however, a substitute for proper error handling. The trade-offs are summarized below.

A standard compromise is to use the OB to set a global flag, write the event ID to a ring buffer DB, and call a function block that raises an HMI alarm. The skeleton in the next section implements this pattern.

8. Module Removal and the Hot-Swap Question

A recurring failure pattern is the engineer who disconnects a module on the workbench to simulate a failure and watches the CPU drop into STOP. The presence of OB83 / OB86 is necessary but not sufficient; the hardware must be configured for “module replacement during operation”.

9. OB Start Information and Diagnostic Buffer

Each error OB receives a fixed-length start info block in the local data stack. The first 20 bytes are common to all OBs; the remaining bytes are OB-specific. The table below lists the most useful variables for S7-1500 OB82/OB83/OB86; S7-300/400 follows the same layout but with a different byte offset in some cases (see the system manual for the exact byte position).

For S7-300/400 in STEP 7 V5.x, the same variables are accessed via the absolute local data stack at fixed offsets (for example OB82_FLT_ID at byte offset 13). The TIA Portal naming convention used above applies to S7-1200/1500 from firmware V2.0 onward.

10. Sample Error OB Bodies (STL, SCL, LAD)

The three code blocks below implement the same pattern: set a global “fault present” flag, write the start info to a ring buffer DB, and acknowledge the event on the diagnostic buffer so the SF LED clears when the cause is removed.

STEP 7 V5.x STL snippet for OB82:

// OB82 - Diagnostic interrupt (S7-300/400)
// Increment ring buffer write pointer
      L     DB99.DB10    // RingBuffer.WriteIndex (WORD)
      +     1
      T     DB99.DB10
      L     64
      MOD
      T     DB99.DB10

// Store fault ID + module address
      L     OB82_MDL_ADDR
      T     DB99.DBD[DB99.DB10 * 8 + 0]
      L     OB82_FLT_ID
      T     DB99.DBB[DB99.DB10 * 8 + 4]

// Set global fault flag
      SET
      =     DB99.DBX14.0   // DiagnosticFaultActive

TIA Portal SCL snippet for OB86 (S7-1500):

// OB86 - Rack/Station failure (S7-1500, SCL)
#RingBuf[#RingBuf.WriteIndex].Timestamp := OB86_DATE_TIME;
#RingBuf[#RingBuf.WriteIndex].FltId      := OB86_FLT_ID;
#RingBuf[#RingBuf.WriteIndex].RackNo     := OB86_RACK_NO;
#RingBuf[#RingBuf.WriteIndex].IoId       := OB86_FLT_IOID;
#RingBuf[#RingBuf.WriteIndex].MdlAddr    := OB86_MDL_ADDR;
#RingBuf.WriteIndex := (#RingBuf.WriteIndex + 1) MOD 64;

// Persistent flag for HMI
"Fault".StationFailed := TRUE;

TIA Portal LAD snippet for OB83:

// OB83 - Insert/Remove interrupt
[OB83_FLT_ID = B#16#63] // 0x63 = module removed
   --("ModuleRemoved") ; HMI alarm tag
[OB83_FLT_ID = B#16#61] // 0x61 = module inserted
   --("ModuleInserted"); HMI alarm tag

11. Verification and Commissioning Procedure

Use the following sequence after loading the error OBs to confirm that the CPU will not enter STOP on a forced fault.

1. Open Online & Diagnostics in TIA Portal (or PLC > Module Information in STEP 7 V5.x). Note the current operating mode and diagnostic buffer state.
2. From Online & Diagnostics > Diagnostics buffer, clear the buffer (right-click > Clear) so the test events are isolated.
3. Force the desired fault. For OB82/OB83, simulate by removing a terminal block on a digital input module of a hot-swap station. For OB86, disconnect the Profibus/PROFINET cable to a DP slave/IO device. For OB85, configure a process image update on a slot that has no module.
4. Verify the CPU remains in RUN. The diagnostic buffer should now show the OB start event followed by the OB exit event.
5. Confirm the SF LED does not latch on once the fault is removed. If it does, the start info was not consumed or the module is still asserting the diagnostic interrupt.
6. Restore the original wiring and confirm the OB exits within the configured monitoring time (default 5 s on S7-1500 for PROFINET station failure).
7. Open Online & Diagnostics > Cycle time / load memory and confirm that the OB execution does not blow the cycle time budget. An OB82 with extensive ring buffer writes can push a 4 ms cycle to 6–7 ms; increase the OB1 watch-dog or trim the code.

12. Troubleshooting Matrix

For further reference, the Siemens Industry Online Support portal publishes a FAQ catalog with examples of programmed error OBs. The legacy entry 42781106 in the Siemens support database is the canonical sample for STEP 7 V5.x; TIA Portal examples are available under the “Application Examples > Error Handling” filter on support.industry.siemens.com. Use the search string “OB82 OB86 S7 example” and filter to “Application” content type to surface the most current code.