Using the Diagnostic Buffer and Fault Logs

When a controller faults, it records why. This record is the single
most direct answer to ‘what happened?’, and reading it should be an
early step in almost every serious fault, not a last resort.

Allen-Bradley: the controller fault log

On a Logix controller, a major fault stops the program and is
recorded with a Type and Code that identify the cause — for example a
category covering I/O faults, another covering program execution errors
such as an array index out of range, and so on. In Studio 5000, the
controller properties dialog has a Major Faults tab showing the fault
type, code, and often the specific instruction and rung involved. Minor
faults are logged separately and do not stop execution but are worth
reviewing when behavior is odd. The pairing of type and code, looked up
against Rockwell’s reference, usually names the cause precisely.

Siemens: the diagnostic buffer

Siemens controllers maintain a diagnostic buffer — a timestamped,
rolling log of events including module faults, communication losses, and
CPU state changes. In TIA Portal, going online and opening the CPU’s
online and diagnostics view shows the buffer with the most recent event
first, each with a plain-language description and often a link to the
affected hardware. Because it is timestamped and historical, the
diagnostic buffer is especially powerful for intermittent problems: it
can show you that a remote I/O rack dropped off the network at 03:14
even though everything looks fine now.

A case file: the mystery night-shift stop

A packaging line stops roughly once a night, always recovers after a
reset, and never fails while day-shift maintenance is watching. Guessing
would be hopeless. Instead, the technician opens the Siemens diagnostic
buffer and finds a series of timestamped entries: a specific PROFINET
drive reporting a communication loss and recovery, each event a few
seconds long, clustered in the early hours. That timestamp pattern is
the whole solution in embryo. It rules out a huge range of causes and
points at the network path to one drive during a specific window.
Following the cable, the technician finds it routed alongside a
high-power circuit that only energizes at night for a cleaning cycle —
classic interference on a marginal connection. The fault log did not
just help; it defined the investigation.

This is the reason to read the log early and always. Even when the
log does not name the exact cause, it timestamps events, and timestamps
convert ‘random’ into ‘patterned.’ A fault that happens at a consistent
time, or always after warm-up, or always when a particular other machine
runs, is a fault with a thread you can pull. Without the log you are
guessing at the pattern; with it you can see the pattern directly.

Clearing faults responsibly

It is tempting to clear a fault and restart to get production moving,
and sometimes that is the right call — but clear with intention. Note
the fault first: its code, its timestamp, the module or instruction it
names. A fault you clear without recording is evidence destroyed. On
controllers where clearing a major fault is required to resume, capture
the details before you clear, so that if it returns you are building a
history rather than starting over each time. A recurring fault that has
been cleared a dozen times without record is a problem the plant keeps
solving and un-solving; the same fault cleared once and documented is a
problem on its way to being fixed.

Minor faults and warnings

Not every logged event stops the machine. Both platforms record minor
faults or warnings that do not halt execution but signal something worth
attention — a battery low, a value approaching a limit, a communication
retry that succeeded. These are easy to ignore precisely because the
machine keeps running, but they are often the early warning of a fault
that will eventually become major. When you are in the log for another
reason, glance at the minor faults and warnings; they sometimes reveal a
developing problem before it takes the line down.

What each platform records, and where to look

It is worth knowing concretely where the record lives on each
platform so you can reach it quickly under pressure. On an Allen-Bradley
Logix controller, major faults appear in the controller properties on a
Major Faults tab, showing the fault type and code and often the program,
routine, and rung where execution stopped; minor faults have their own
tab. The type-and-code pair, looked up in Rockwell’s reference, names
the fault category and specific cause. On a Siemens S7-1200 or S7-1500,
the diagnostic buffer is reached by going online and opening the CPU’s
online and diagnostics view, where events appear newest-first, each
timestamped and described in plain language, frequently with a direct
link to the affected hardware. Knowing these paths cold means that when
a controller faults, you are reading the cause within a minute rather
than hunting through menus while the line sits idle.

The log as a story over time

A single fault entry answers ‘what happened,’ but the log read as a
sequence answers the more valuable question of ‘what happened first.’
Faults often cascade: a root failure triggers dependent failures, each
logging its own entry, and the entry that stopped the machine may be
several steps removed from the cause. Reading the log in time order,
oldest of the cluster first, tends to reveal the root event before the
cascade buried it. This is the same principle as reading HMI alarm
history in order: the first event in a burst is usually closest to the
cause, and the later ones are consequences. Train yourself to look for
the first entry in a cluster rather than the last or the most alarming,
because the machine records the cascade in the order it happened, and
that order is a map back to the root.

Communication faults in the log

A large share of logged faults on modern distributed systems are
communication faults, and learning to read them saves enormous time
because the log names exactly what went silent. When a networked device
loses communication, the controller logs it against that specific
device, by name or address, with a timestamp. This is far more precise
than a bare ‘machine fault,’ because it tells you which of possibly
dozens of networked devices dropped and when. A log full of
communication faults against one particular device points at that
device’s connection — its cable, its addressing, its power, its network
path. A log showing many devices dropping together points at a shared
element like a switch or a segment. And the timestamps turn intermittent
communication faults into patterns you can correlate with other events.
Reading communication faults in the log — which device, when, and
whether alone or with others — localizes network problems with a
precision that tracing cables blindly could never match.

Using the log to verify a fix

The fault log is not only for diagnosis; it is also how you prove a
fix held. After repairing a fault, especially an intermittent one, the
log becomes your evidence over the following hours or days that the
fault has genuinely stopped recurring rather than merely being quiet for
the moment. For an intermittent fault that logged an event each time it
occurred, a clean log across a period that previously would have shown
several occurrences is real confirmation the fix worked, in a way that
watching the machine run briefly cannot provide. This closes the loop
properly: you diagnosed from the log, you repaired, and you return to
the log to confirm the pattern of faults has stopped. For faults that
are hard to reproduce on demand, this after-the-fact confirmation from
the log is often the only solid proof that the repair addressed the real
cause, and it guards against declaring victory prematurely on a fault
that was merely between occurrences.

A case file: reading the buffer to find a dropping
drive

A machine stops intermittently with a communication-related fault,
and because it is intermittent and communication-related, the diagnostic
buffer with its timestamped history is the natural first resource.
Opening the Siemens diagnostic buffer, the technician finds a clear
record: a specific drive repeatedly logging communication loss and
recovery, each event timestamped, clustered in a pattern. This record
does several things at once. It names the specific drive, so the
investigation focuses on one device rather than the whole network. It
timestamps the events, so their pattern can be correlated with other
happenings. And it distinguishes a communication problem from a
drive-hardware or motor problem, directing attention to the network path
to that drive rather than to the drive’s power section or the motor.
Following this precise lead — the network path to one named drive,
failing at recorded times — the technician traces the cabling and finds
it running alongside a circuit that energizes intermittently, coupling
interference into a marginal connection. The buffer did not merely help;
it defined the entire investigation, converting a vague intermittent
stop into a specific named drive with a timestamped failure pattern on a
specific network path. This is the recurring value of the timestamped
fault log for intermittent and communication faults: it names what
failed and when with a precision that no amount of watching a
currently-healthy machine could provide, and reading it early turns
investigations that would otherwise flounder into directed pursuits of a
specific device and a specific pattern.

Part III — Inputs