Start with the CPU LEDs, then open the diagnostic buffer, which timestamps every fault the CPU has recorded. Go online to the block and read the live logic. Use the cross reference list to find every place a tag is written. Use a watch table to observe and modify values, and force only when nothing else will do, removing every force before you leave.
- The diagnostic buffer is the first place to look and the most often skipped.
- Cross references answer 'what else writes this tag' in seconds; searching networks by eye does not.
- Forcing overrides the physical signal and stays active until removed; treat it as a controlled, documented action.
Work in This Order
Under pressure, people start changing code. The fastest route is almost always diagnosis before modification.
- LEDs on the CPU and modules. RUN, STOP, ERROR and MAINT tell you the category before you open a laptop.
- Diagnostic buffer. Timestamped record of what the CPU itself noticed.
- Device view online. Which module reports a fault, and on which channel.
- Online blocks. Read the live logic where the machine actually stopped.
- Cross references. Find every write to the suspect tag.
- Watch table. Observe values, then modify only if safe.
- Force. Last resort, documented, removed before handover.
| LED state | Meaning | First check |
|---|---|---|
| RUN green steady | CPU running normally | Fault is in logic or field, not the CPU |
| ERROR red flashing | Fault the CPU has recorded | Diagnostic buffer |
| STOP yellow | CPU stopped | Diagnostic buffer for the stop cause |
| MAINT yellow | Maintenance required | Module diagnostics, often a channel fault |
| All dark | No power or CPU failure | Supply voltage and fuses |
The Diagnostic Buffer and Module Status
Go online and open the CPU's diagnostic buffer. It holds a timestamped list of events: CPU stops with their cause, module faults, communication losses, programming errors and mode changes.
Read from the bottom of the incident upward. The last entry is often a consequence; the entry two or three earlier is usually the cause. A CPU stop preceded by a diagnostic error on an input module points at the module, not the program.
Module and channel diagnostics
The online device view shows which module is reporting and, for most modules, which channel. Analog modules report wire break, overrange and underrange per channel, which identifies a failed transmitter without a multimeter.
- Wire break on an analog input usually means a broken loop or a dead transmitter.
- Overrange with a plausible process value often means wrong scaling rather than a fault.
- A missing PROFINET device shows as a station failure with its device name, which is your first clue on the network side.
Capture the diagnostic buffer before restarting the CPU. A restart clears the situation, and with it the evidence.
Online Blocks, Cross References and Watch Tables
Open the relevant block online. Ladder shows live contact and coil states in colour, so a permissive chain reveals its open contact immediately.
Cross references
Right-click a tag and open cross references. The list shows every block and network that reads or writes it. This is the fastest way to find a double write, which is the cause of most "the logic is right but the output is wrong" calls. The mechanism is explained in the PLC scan cycle.
Watch tables
A watch table lets you observe many tags at once, across blocks, with the display format you choose.
| Action | What it does | Risk |
|---|---|---|
| Monitor | Reads values live | None |
| Modify once | Writes a value for one scan | The program can overwrite it immediately |
| Modify permanently | Writes continuously while active | Real movement on real machines |
| Force | Overrides the physical signal at the module | Persists until explicitly removed |
Build a watch table per machine area and save it with the project. Next time the same fault appears, the diagnostic setup is already there.
Learn troubleshooting on live faults
Sessions include fault-injection exercises on real Siemens hardware, not just theory.
Forcing, and the Faults That Are Not Program Faults
Forcing overrides a signal at the module, so the program cannot change it. It is powerful and it is remembered by the CPU.
- Force only with the machine in a known safe state and the affected drive isolated where possible.
- Record every force: which tag, why, by whom, when.
- Remove all forces before handover and confirm the force table is empty.
- Never leave site with a force active; a forced input on a running plant is a genuine hazard.
When the program is not the problem
A large share of "PLC faults" are not in the PLC at all. Before editing code, confirm:
| Symptom | Check first |
|---|---|
| Output true in software, nothing in the field | Output module fuse, wiring, contactor coil |
| Input never turns on | Sensor supply, sensor type against module type, terminal |
| Intermittent PROFINET station failure | Cable, connector, switch port, cable route near a VFD |
| Analog value drifting or noisy | Shield earthing, cable routing, transmitter health |
| CPU stops under load | Cycle monitoring time, loop in the program, power supply |
Document what you found and what you changed. The next person to face this fault at 3 a.m. may well be you.
Hands-On Lab: Diagnose Three Injected Faults
Hands-on- TIA Portal with an S7-1200 or S7-1500 CPU, or PLCSIM
- A working test program you can deliberately break
- A colleague to inject faults without telling you which
- Estimated time: 45 minutes
Establish a baseline
Record the diagnostic buffer, cycle time and a healthy watch table for the working program.
Diagnose a double write
Have a fault injected where an output is written in two places, then find it.
Diagnose a module fault
Simulate an analog wire break or remove a station, then trace it.
Diagnose a cycle time fault
Inject a heavy loop until cycle monitoring is exceeded.
Practise a controlled force
Force one input, document it, then remove it and confirm the force table is empty.
You can diagnose each fault using diagnostics rather than code changes, and you finish with an empty force table and a written record.
Frequently asked questions
Where do I start when a Siemens PLC faults?
The CPU LEDs, then the diagnostic buffer. It timestamps every event the CPU recorded, including the cause of a stop, and it is the step most often skipped.
What is the difference between modify and force?
Modify writes a value that the program can immediately overwrite. Force overrides the signal at the module so the program cannot change it, and it stays active until explicitly removed.
How do I find why an output ignores its logic?
Open cross references for that tag. The output is almost certainly written in a second place later in the program, and the later write wins.
Why does the CPU go to STOP under load?
Usually the cycle monitoring time is exceeded, often by a loop or a heavy calculation. The diagnostic buffer records the time error and its timestamp.