Reading the Siemens Diagnostic Buffer: Finding Why an S7-1200 or S7-1500 Stopped
The short answer
When a Siemens CPU goes to STOP, the reason is in the diagnostic buffer, in plain language, with a timestamp. Go online in TIA Portal, open Online and diagnostics for the CPU, and read the buffer from the top. The most recent entry is the stop event and the entries below it are the sequence that led there. Almost every field STOP is one of six causes, and most of them are avoidable in the program.
Getting to it
Online and diagnostics on the CPU, then Diagnostics, then Diagnostics buffer. It survives a power cycle, it is timestamped, and each entry expands to show the block and the network where the event occurred.
Two things worth setting up before you need them. The CPU clock should be synchronised, because a buffer full of events timestamped from 1990 tells you the order but not the shift. And the buffer is a ring: on a CPU generating frequent events it will overwrite, so capture it before you start experimenting.
The entry
Each entry gives you an event, a time, and usually the block, the network and the operand. The useful habit is to read from the bottom of the incident upwards: the first event in a sequence is the cause, and the STOP at the top is only the consequence.
The six causes behind most stops
Programming error, no OB121. An indirect access outside an array, an index calculated from a value that went out of range, a pointer built at runtime. Without OB121 in the project, the CPU stops. With OB121, the error is logged and the program continues, which is right for some machines and wrong for others; decide deliberately rather than by omission.
Access error to hardware, no OB122. Reading or writing I/O that is not there: a module removed, a distributed rack offline, a PROFINET device that has not come up. Same rule, OB122 catches it.
Cycle time exceeded, no OB80. A loop that occasionally runs longer, a communication instruction that blocks, or a badly written FOR loop over a large array. The cure is nearly always in the program rather than in raising the cycle monitoring time.
Rack or station failure. A PROFINET device dropped, and the CPU stops if OB86 is absent. In practice this is a cable, a switch, an SFP, or a device that reboots for its own reasons.
Configuration mismatch. The hardware in the rack is not the hardware configured: a different module order number, a firmware version outside the configured range, or a device name that does not match the PROFINET configuration.
Memory. Work memory exhausted after a download, or a data block created larger than the CPU has room for.
What an OB does and does not do
Adding OB121, OB122, OB80 and OB86 to a project stops those events being fatal. It does not fix them. A machine that runs with an empty OB121 is a machine where an addressing bug is being swallowed silently, and the fault will surface later as wrong behaviour rather than as a stop.
The right pattern is to add the OB, log the event to a diagnostic data block with enough context to identify it, and raise an operator-visible fault where the condition matters. Then fix the cause.
Before you call it a hardware fault
Check the module LEDs and the CPU error LED first. Then confirm the diagnostic buffer entry names a specific module. Then check whether the same entry appears at the same time each day, which usually means a scheduled task, a shift change or a large motor starting nearby rather than a failing card.
Where to learn it properly
The Siemens TIA Portal course covers the CPU, the hardware configuration and going online. The commissioning, simulation and troubleshooting course covers diagnostics specifically, and the organisation blocks, interrupts and timers course covers the OBs above and when each fires. Related reading: PLC scan cycle and rung order and PLC troubleshooting: common faults.
Frequently asked questions
Can I read the buffer without TIA Portal? The CPU web server exposes it if enabled, which is worth turning on before commissioning ends because it means a diagnostic can be read from a phone on the plant network.
Does the buffer clear on download? A full download with memory reset clears it. Capture it first: this is a common way of destroying the only evidence of an intermittent fault.
S7-300 and S7-400? Same concept, same OB numbers, read through the older tooling or through TIA Portal where the project has been migrated. See the S7-300 with STEP 7 course.
