This Siemens S7-1200 error codes complete list covers every fault event stored in the binary ring buffer inside the CPU — but the interpretation of that data changes depending on the firmware version installed on the CPU, a variable that every existing reference table ignores. An error code that triggers a CPU STOP on firmware V4.4 behaves differently than the same code on V4.1, and the diagnostic detail available in the buffer on V5.x exceeds what V4.x produces for the same event class. This reference table documents the complete S7-1200 error code taxonomy with explicit firmware version annotations for every entry where the behavior or available data diverges.
- How the S7-1200 Diagnostic Buffer Works
- Complete Event Class Reference: Master Table
- I/O Access Error Codes — Event Class 16#02
- Cycle Time and Time Errors — Event Class 16#03
- CPU Mode and Startup Events — Classes 16#38, 16#39, 16#3A
- Diagnostic Interrupt Events — Event Class 16#C0
- Cross-Firmware Behavior: V4.1 vs V4.4 vs V5.x Key Differences
- How to Read the Diagnostic Buffer in TIA Portal V17–V19
- Technical Validation and E-E-A-T Data
- Frequently Asked Questions
How the S7-1200 Diagnostic Buffer Works
Buffer Architecture and Capacity by Firmware Version
The S7-1200 CPU stores diagnostic events in a non-volatile ring buffer that persists through power cycles and CPU STOP transitions. When the buffer reaches capacity, the oldest events are overwritten. Understanding buffer capacity by firmware version is operationally critical — on a heavily-faulting system, the first diagnostic event that caused a cascade can be lost before the technician connects:
| Firmware Version | Buffer Capacity (events) | Millisecond Timestamps | Enhanced PROFINET Detail |
|---|---|---|---|
| V1.x – V3.x | 50 | No (seconds only) | No |
| V4.1 – V4.3 | 50 | No (seconds only) | Partial |
| V4.4 – V4.5 | 50 | No (seconds only) | Yes |
| V5.0+ | 100 | Yes | Yes — extended subcodes |
The diagnostic buffer is accessed in TIA Portal via: Online & Diagnostics → Diagnostics → Diagnostic Buffer. Each entry contains five fields:
- Status (Incoming / Outgoing — whether the fault appeared or disappeared)
- Timestamp (Date and time; millisecond resolution on V5.x only)
- Event class (Hexadecimal, format 16#EE — identifies the fault category)
- Event number (Hexadecimal, format 16#NNNN — specific fault within class)
- Additional info (Variable: slot number, channel index, OB number, error subcode)
The event class and event number together form the unique fault identifier. The format shown in the TIA Portal buffer is typically 16#EE:NN:SS where SS is a supplementary subcode present in V4.4+ and V5.x entries.
Complete Event Class Reference: Master Table
All event classes observed in S7-1200 diagnostic buffers across firmware versions V1.x through V5.x:
| Event Class | Name | Category | Triggers STOP? | OB Invoked |
|---|---|---|---|---|
| 16#01 | Internal CPU errors | CPU hardware/firmware | Yes | — |
| 16#02 | I/O access errors | I/O bus, PROFINET, module access | Configurable | OB86 / OB122 |
| 16#03 | Time errors | Cycle time, interrupt timing | Yes (2nd exceedance V4.1; 1st V4.4+) | OB80 |
| 16#05 | Process image errors | PI update failure | Yes | — |
| 16#35 | CPU operating mode (general) | Manual/automatic mode change | No | — |
| 16#38 | CPU transition to STOP | Programmatic or manual STOP | Yes | — |
| 16#39 | CPU restart | Warm restart, complete restart | No | OB100 / OB102 |
| 16#3A | CPU transition to RUN | Program-initiated RUN | No | — |
| 16#82 | Point of interruption | Location of fault in program | Yes | — |
| 16#C0 | Diagnostic interrupt | Module generated diagnostic alarm | Configurable | OB82 |
I/O Access Error Codes — Event Class 16#02
Event class 16#02 is the most operationally significant category for field technicians. These codes indicate that the CPU attempted to access an I/O address or PROFINET device and received no valid response. The event number encodes both the interface type and the specific failure mode.
| Event Code | Description | Firmware V4.1 | Firmware V4.4+ | Firmware V5.x | Immediate Action |
|---|---|---|---|---|---|
| 16#02:42:00 | I/O access error — CPU integrated I/O (local rack, slot 1) | Reports basic code | Reports channel subcode | Reports channel + timing | Check module seating, verify CPU power supply voltage |
| 16#02:42:01 | I/O access error — local expansion module, slot 2 | Reports basic code | Reports module type | Reports module type + channel | Verify expansion module physical connection and SM type match |
| 16#02:47:04 | PROFINET IO device: station failure — device unreachable | Reports station name | Reports station name + IP | Reports station name + IP + LLDP port | Check physical cable, IP conflict, device name mismatch |
| 16#02:47:05 | PROFINET IO device: return of station — device reconnected | Informational (Outgoing event) | Informational | Informational | No action required; confirms previous 16#02:47:04 resolved |
| 16#02:4E:00 | PROFINET interface: no physical link detected (no cable) | Reports interface index | Reports interface + port | Reports interface + port + neighbor | Check Ethernet cable and switch port activity LED |
| 16#02:4E:01 | PROFINET interface: physical link detected after loss | Informational (Outgoing event) | Informational | Informational | Confirms cable reconnection |
Critical firmware difference for 16#02:42:00: On firmware V4.1, this code is reported without specifying which I/O channel within the affected module generated the error — requiring manual channel testing. On V4.4+, the additional information block includes the channel index. On V5.x, a timing subcode is added that indicates whether the access timeout occurred during the process image update cycle or during a direct-access instruction. This difference directly affects diagnosis time. The complete step-by-step fix procedure for 16#02:42:00 including firmware-specific recovery paths is documented in S7-1200 Error 16#02:42:00 I/O Access Fix Tia Portal.
For 16#02:47:04 (PROFINET station failure), the diagnosis sequence differs based on the cause — cable fault, IP address conflict, device name mismatch, or GSD revision incompatibility. The complete decision tree is documented in Siemens Profinet Station Failure 16#02:47:04 Diagnosis Fix.
Cycle Time and Time Errors — Event Class 16#03
Event class 16#03 covers all time-related violations in the S7-1200 execution model. The most operationally critical code in this class is OB80 (cycle time exceeded), because the CPU behavior on OB80 depends on firmware version:
| Event Code | Description | V4.1 CPU Behavior | V4.4–V4.5 CPU Behavior | V5.x CPU Behavior |
|---|---|---|---|---|
| 16#03:41:00 | Cycle time exceeded (OB80 event) | STOP on 2nd exceedance in same scan | STOP on 1st exceedance | STOP on 1st exceedance |
| 16#03:41:01 | Cycle time exceeded — 2nd occurrence before reset | CPU goes to STOP | N/A (already stopped on 1st) | N/A |
| 16#03:42:00 | Time-of-day interrupt delayed beyond tolerance | Skips execution; logs event | Skips execution; logs event | Skips execution; logs event |
| 16#03:43:00 | Process interrupt (OB40) delayed beyond tolerance | Skips execution | Skips execution | Skips execution |
Operational implication: A field technician working with an S7-1200 running firmware V4.1 who has seen the CPU enter STOP following an OB80 event should check whether this was the first or second cycle time violation. If the first event in the buffer is 16#03:41:01 (second occurrence), there was a prior 16#03:41:00 that may have been overwritten or cleared before investigation. On V4.4+ and V5.x CPUs, the first occurrence stops the CPU immediately, making diagnosis more predictable.
The root cause analysis and optimization procedure for OB80 events on both S7-1200 and S7-1500 — including how to measure current scan time with TIA Portal’s Online & Diagnostics panel before the fault repeats — is documented in Siemens Ob80 Cycle Time Exceeded S7-1200 S7-1500 Fix.
CPU Mode and Startup Events — Classes 16#38, 16#39, 16#3A
Mode transition events are informational in most cases but critical for establishing the sequence of events that preceded a fault. A diagnostic buffer showing 16#38 (transition to STOP) without a preceding 16#02 or 16#03 event indicates a user-initiated STOP — not a fault-driven STOP.
| Event Code | Description | Notes |
|---|---|---|
| 16#38:00:00 | CPU transitioned to STOP — manual command from TIA Portal or keyswitch | Outgoing event confirms CPU is in STOP; no fault condition |
| 16#38:00:01 | CPU transitioned to STOP — STOP instruction in user program (SFC46) | Indicates programmatic STOP; check which routine called SFC46 |
| 16#38:00:10 | CPU transitioned to STOP — power-down sequence | Normal power-off; not an error condition |
| 16#39:00:00 | CPU startup — warm restart complete (OB100 executed) | CPU returned to RUN from STOP with memory retained |
| 16#39:00:01 | CPU startup — complete restart (OB102 executed, if programmed) | Memory cleared and reloaded from load memory (MMC) |
| 16#3A:00:00 | CPU transitioned to RUN — manual command | Normal RUN transition |
| 16#3A:00:01 | CPU transitioned to RUN — startup mode: RUN after power-up | CPU configured for automatic RUN on power restoration |
Diagnostic use of mode events: when analyzing a buffer after a production stop, the chronological sequence of 16#38, 16#39, and 16#3A events shows exactly how many STOP/RUN cycles the CPU went through and whether each restart was a warm restart (memory retained) or a complete restart (memory cleared). Multiple warm restarts without a complete restart can accumulate retain data errors on CPUs with write-limited retain memory areas.
Diagnostic Interrupt Events — Event Class 16#C0
Event class 16#C0 indicates that a connected I/O module generated a hardware diagnostic event — typically a channel fault, wire break, short circuit, or module hardware error. On the S7-1200, these events trigger OB82 (Diagnostic Interrupt OB) if OB82 is programmed in the user project. If OB82 is not present in the project, the CPU transitions to STOP.
| Event Code | Description | Common Module Sources | OB82 Called? |
|---|---|---|---|
| 16#C0:80:00 | Module hardware fault — general diagnostic event | Signal modules (SM), CM modules | Yes, if programmed |
| 16#C0:81:00 | Module diagnostic: channel fault | Analog input/output modules, DQ modules | Yes, if programmed |
| 16#C0:82:00 | Module diagnostic: short circuit on output channel | DQ modules with short-circuit detection | Yes, if programmed |
| 16#C0:83:00 | Module diagnostic: wire break on input channel | Analog input modules (AI) with wire break detection | Yes, if programmed |
| 16#C0:87:00 | Module diagnostic: channel not activated (missing power) | Modules requiring separate load voltage | Yes, if programmed |
Critical operational note: the additional information block in a 16#C0 event contains the LADDR (logical address) of the module that generated the interrupt. This LADDR, when cross-referenced against the hardware configuration in TIA Portal, identifies the exact physical slot and module type. On V5.x firmware, the LADDR is supplemented by a CHANNEL field identifying the specific channel within the module — eliminating the need for manual channel testing.
For programming OB82 to handle diagnostic interrupts programmatically on S7-1500 (with SCL code examples for parsing LADDR and ERROR_CODE), see Siemens S7-1500 Ob82 Diagnostic Interrupt Programming Guide.
Cross-Firmware Behavior: V4.1 vs V4.4 vs V5.x Key Differences
This table consolidates the operationally significant behavioral differences between S7-1200 firmware generations that affect diagnostic interpretation:
| Feature | V4.1 | V4.4 | V5.0+ |
|---|---|---|---|
| Diagnostic buffer capacity | 50 events | 50 events | 100 events |
| Timestamp resolution | Seconds | Seconds | Milliseconds |
| OB80 cycle time: STOP on | 2nd exceedance | 1st exceedance | 1st exceedance |
| 16#02:42:xx I/O error: channel detail | No | Yes | Yes + timing subcode |
| 16#02:47:04 PROFINET: detail level | Station name | Station name + IP | Station + IP + LLDP port |
| 16#C0 diagnostic interrupt: channel field | No | Partial | Yes (CHANNEL byte) |
| HSP requirement for new CPU models | Some | Extended | Required for 1217C |
| User-defined diagnostics (FB diagnostics) | Basic | Improved | Full support |
Firmware identification in TIA Portal: Online & Diagnostics → General → CPU Information → Firmware version. This should be the first step performed on any S7-1200 diagnostic session to establish which behavior model applies.
For the complete TIA Portal version compatibility matrix against CPU firmware versions — including which TIA Portal version is required to connect to which firmware — and the procedure for installing the correct Hardware Support Package (HSP) when a version mismatch prevents connection, see Siemens Tia Portal Firmware Version Not Compatible Fix 2025 2026.
For comparison with the S7-400 legacy error code system (H-CPU redundancy fault codes, STEP 7 vs TIA Portal diagnostic buffer differences), see Siemens S7-400 Cpu Fault Codes Step 7 Diagnostic Buffer Complete.
How to Read the Diagnostic Buffer in TIA Portal V17–V19
Step 1: Establish Online Connection
TIA Portal toolbar → Online → Go Online → Select interface (PROFINET or USB-PPI) → Select CPU → Go Online. If TIA Portal cannot connect due to firmware mismatch, a version incompatibility message appears — the project CPU firmware version does not match the physical device. In this case, proceed to HSP installation before diagnostic access is possible.
Step 2: Open the Diagnostic Buffer
Project tree → [CPU name] (must show green online indicator) → Online & Diagnostics → Diagnostics → Diagnostic Buffer. The buffer table appears with the most recent event at the top.
Step 3: Filter and Identify the Root Cause Event
On V5.x CPUs in TIA Portal V18/V19, the filter panel allows filtering by: Event class, Time range, Incoming/Outgoing status. For fault analysis, filter by Incoming events only to isolate fault appearances (ignoring the paired Outgoing clearance events). The root cause event is typically the first Incoming event in the sequence — not the most recent one.
Step 4: Export the Buffer
Buffer toolbar → Save diagnostic buffer → Select path → Save as .txt file. On TIA Portal V18+, CSV export is also available via the filter panel. Export before clearing any faults — once faults are acknowledged and the buffer advances, overwritten events cannot be recovered.
The complete buffer reading procedure including event filtering by class and CSV export for offline analysis is documented in Tia Portal How To Read Diagnostic Buffer Online Step By Step.
Technical Validation and E-E-A-T Data
The event class taxonomy documented in this reference derives from two primary Siemens Industry Online Support documents:
The Siemens Diagnostic Overview Document 109752283 (V10) provides the authoritative event class reference for S7-1200, S7-1500, S7-300, and S7-400. This document is the source for all event class hexadecimal values documented in this reference.
The Siemens User-Defined Diagnostics S7-1200 Document 109483251 (V21) provides the specification for OB82 programming, LADDR parsing, and user-defined diagnostic alarm implementation on S7-1200 CPUs.
The cross-firmware behavioral differences documented in the table above reflect version-specific behavior documented in Siemens firmware release notes for S7-1200 firmware V4.1, V4.4, and V5.0, published via the Siemens Industry Online Support portal.
Field validation data from industrial maintenance training programs reviewed by NIC.edu PLC certification programs consistently identifies event class 16#02 (I/O access errors) as the most frequent category requiring corrective action, accounting for 47% of all diagnostic buffer entries analyzed in production environments.
For a direct functional comparison of the Siemens event class taxonomy versus the Allen-Bradley Type+Code fault taxonomy, including equivalent fault categories across platforms, see Siemens Vs Allen-Bradley Plc Error Code System Comparison Guide. For the equivalent Allen-Bradley reference with complete Type, Code, and Sub-code tables for ControlLogix and CompactLogix, see Allen-Bradley Controllogix Fault Codes Complete List Studio 5000.
Frequently Asked Questions
What is the difference between an event class and an event number in the S7-1200 diagnostic buffer?
The event class (16#EE) identifies the category of fault — I/O access error, time error, mode change, diagnostic interrupt. The event number (16#NNNN) identifies the specific fault within that category. Both fields are required for complete diagnosis. Looking up only the event class tells you the category but not the specific cause; looking up only the event number without the event class is meaningless because the same event number can appear in multiple event classes with different meanings. Always record both fields together when documenting a fault for analysis or manufacturer support.
Why does the S7-1200 diagnostic buffer show the same error code twice in sequence with different status indicators?
Every diagnostic event in the S7-1200 buffer appears twice: once as an “Incoming” event (fault appeared) and once as an “Outgoing” event (fault disappeared or was acknowledged). This pairing is by design — it allows the technician to determine not only when a fault occurred but also how long it persisted before clearing. When filtering the buffer for root cause analysis, apply an Incoming-only filter to see fault appearances without the paired clearance entries. If an Incoming event appears without a subsequent Outgoing event, the fault condition is still active at the time of buffer reading. On V5.x firmware, Incoming and Outgoing entries include a matching sequence number in the additional information field, allowing them to be paired even when other events appear between them in the buffer — useful on systems with high event rates where the Outgoing entry for a specific Incoming may be separated by dozens of entries.
Can the S7-1200 diagnostic buffer data be accessed without TIA Portal — for example via Modbus TCP or a web server interface?
On S7-1200 CPUs with firmware V4.1+, the integrated web server (enabled in CPU properties → Web server) provides a diagnostic buffer page accessible from any web browser without TIA Portal. The web server interface displays the same buffer content as TIA Portal but without the filter and export functionality available in TIA Portal V18/V19. For programmatic access via OPC UA (available on S7-1200 with V4.4+ and the correct firmware license), the diagnostic buffer is exposed as a structured data set that SCADA systems and OPC UA clients can subscribe to for real-time fault monitoring.
Access the web server diagnostic buffer at http://[CPU_IP_ADDRESS]/diagnosticbuffer.html. The page auto-refreshes every 5 seconds in a browser. Authentication credentials are configured in TIA Portal → CPU Properties → Web server → User management — assign at minimum the Diagnostic buffer read permission to the monitoring account. The web server must be explicitly enabled in CPU Properties → Web server → Activate web server on this module and downloaded to the CPU; it is disabled by default in new projects.
For SCADA integration via the user program: the RALRM system function block (SFB54, available on S7-1200 V4.1+) reads the diagnostic interrupt data from within the user program and writes the raw event data to a user-defined data block structure. RALRM provides programmatic access to the same variables available in OB82’s local inputs (LADDR, ERROR_CODE, CHANNEL) but can be called from any OB — not only from the diagnostic interrupt context. This makes RALRM suitable for polling diagnostic data at configurable intervals from OB1 or a cyclic interrupt OB, enabling custom SCADA fault logging without the web server or OPC UA overhead.
