When something's wrong on a live machine, you don't guess — you go online and look. The CPU keeps a diagnostic buffer: a timestamped, tamper-proof log of every meaningful event, newest on top. Pair it with a watch table to see live tag values, and you can chase any fault to ground. Poke the machine below and watch the log write itself.
Left is the buffer, right is a watch table monitoring four tags. Every action you take on the deck below — switching mode, tripping an overload, pulling a module — lands in the buffer with a timestamp and an event code, just like the real CPU. Note how a fault that puts the CPU in STOP is captured with its cause: that one entry usually solves the case.
| Tag | Value | Force |
|---|---|---|
| "Conveyor".run | FALSE | |
| "Motor".current | 3.2 A | — |
| "Line".speed | 0 /min | — |
| "ET200".online | TRUE | — |
A forced value is held by the programmer, overriding logic AND the physical wire — the CPU shows a warning while any force is active. Use it to test, never to "fix."
This is the order of every real debug session: go online → read the diagnostic buffer → watch the suspect tags → force an input to test a theory. The CPU is never a black box if you know these three windows. (The Trace tool adds high-speed recording on top, and the built-in web server shows the buffer from a browser.)
📓 Diagnostic buffer — the timestamped event log. Mode changes, module faults, programming errors — the first place to look, always.
👁️ Watch & force tables — monitor any tags live; force a handful to fixed values to test wiring and logic safely.
📈 Trace — records selected tags at the cycle clock, so you can catch a glitch too fast for the eye and view it as a scope plot.
🌐 Web server — the CPU serves its own diagnostics page over HTTP. Eyes on the buffer and module status from any browser, no TIA needed.
A machine tripped to STOP overnight. Nobody saw it. What's the single fastest first step to find out why?