Most production machines present their faults through an HMI — a
touchscreen showing alarms in plain language. This is often your first
and best clue, but it must be read critically. An HMI alarm reports a
symptom the machine’s designers anticipated; it points you toward the
cause but rarely names it outright.
Turning an alarm into an investigation
A message like ‘Infeed conveyor not at position’ does not mean the
conveyor is the broken part — it means a position sensor did not report
the expected state within the expected time. The alarm hands you the
exact condition the machine was waiting for, which is precisely what you
need. Read the alarm, identify the specific device or condition it
names, and then use the earlier chapters to verify that device: is the
sensor sensing, is the signal arriving, is the logic satisfied? Many
HMIs also keep an alarm history with timestamps, which, like the
controller’s fault log, is invaluable for intermittent problems.
When the HMI and the field disagree
Occasionally the HMI insists on a fault that the field contradicts —
it reports a guard open when the guard is closed, for instance. This is
itself a strong diagnostic: it tells you the machine genuinely sees the
guard as open, so the fault is in the sensing chain (switch, wiring,
input) rather than in the guard. Trust that the controller is reporting
what it actually sees, then find why what it sees differs from
reality.
An alarm is a designed message, not the truth
itself
It is worth being clear-eyed about what an HMI alarm is. Someone
programmed that alarm to appear when a specific condition was detected —
usually a signal not reaching an expected state within an expected time.
The alarm text is their description of what that condition means,
written in advance, and it points toward a cause without being the
cause. ‘Clamp not retracted’ does not mean the clamp is broken; it means
the sensor that confirms retraction did not report retracted when the
logic expected it. That could be the clamp, the sensor, the sensor’s
wiring, the input, or even a timing problem where the clamp retracted
too slowly. The alarm is a precise pointer to a condition, which is
exactly what you want — provided you read it as a starting point for
investigation rather than a diagnosis to act on blindly.
Alarm history as a diagnostic record
Most HMIs keep a timestamped alarm history, and like the controller’s
fault log it is invaluable, especially for intermittent and cascading
faults. A cascading fault is one where a single root problem triggers a
flurry of alarms as dependent systems fail in turn, and the alarm that
catches your eye may be far downstream of the real cause. The history,
read in time order, often shows the first alarm that fired — the root —
before the cascade obscured it. When you face a screen full of alarms,
do not react to the loudest or the last; find the first, because the
first alarm in a cascade is usually closest to the cause while the rest
are consequences.
When the machine and reality disagree
A particularly informative situation arises when an alarm contradicts
what you can see — the HMI reports a guard open while the guard is
plainly closed, or a low level while the tank is full. Rather than
dismissing this as a glitch, treat it as a precise clue. The controller
is reporting what its sensors actually tell it, so a contradiction means
the sensing chain is lying to the controller: the guard switch, its
wiring, or its input is telling the controller ‘open’ regardless of the
guard’s real position. This localizes the fault immediately to the
sensing chain and away from both the guard itself and the logic.
Trusting that the controller faithfully reports what it senses, then
hunting for why what it senses differs from reality, turns a confusing
contradiction into a narrowed search.
A case file: the alarm that named the wrong part
An HMI alarm reads ‘hydraulic pressure low’ and the operator has
already called for a new pump. But the alarm names a symptom the machine
detected — a pressure signal below a threshold — not a diagnosis. Before
condemning the pump, the technician verifies the sensing chain the alarm
depends on. Metering shows the actual hydraulic pressure is normal; the
pressure is fine, yet the controller reads it as low. The fault is in
the pressure sensing chain — as it turns out, a failing pressure
transmitter reporting far below the true value. The pump was never the
problem. Replacing the transmitter clears the alarm and the pump is
untouched. This is the discipline the chapter urges made concrete: an
alarm points at a condition the machine detected, and that condition can
be false because the sensing that produced it has failed. Verify what
the alarm depends on before acting on what the alarm names, or you will
replace healthy parts on the machine’s mistaken word.
Designing your reading of an alarm screen
Faced with an HMI showing multiple active alarms, a deliberate
reading beats reacting to whichever alarm is most prominent. First, look
for the alarm history in time order to find which alarm fired first,
since in a cascade the first is usually nearest the root and the rest
are consequences. Second, for the root alarm, identify the specific
device or condition it names — the exact signal the machine was waiting
on. Third, resist acting on the alarm’s surface meaning until you have
verified that underlying condition in the field. This ordered reading —
first alarm first, name the condition, verify before acting — turns a
chaotic screen of alarms into a directed investigation of a single root
cause, and it guards against the twin traps of chasing consequences
instead of causes and trusting an alarm that a failed sensor has made
false.
Alarms, events, and the difference
HMIs distinguish between alarms that demand attention and events that
merely record what happened, and reading both, aware of the difference,
gives a fuller picture than watching alarms alone. An alarm signals a
condition requiring action — a fault, a limit exceeded, a required
intervention — and typically demands acknowledgment. An event log
records normal occurrences — a cycle started, an operator changed a
setting, a mode was selected — without demanding action. For
troubleshooting, the event log is an underused resource, because it
records the context around a fault: what the machine was doing, what
settings were in effect, what the operator did in the moments before the
alarm. A fault that only occurs in a particular mode, or after a
particular operator action, or with a particular setting, reveals that
dependency in the event log even when the alarm itself gives no such
hint. Reading the event log alongside the alarm history, to see not just
that a fault occurred but what surrounded it, often exposes a dependency
— a mode, a setting, an action — that turns a mysterious intermittent
alarm into a reproducible, understood one.
When alarms are poorly designed
Not all alarm systems are well designed, and recognizing a poor one
prevents it from misleading you. Some machines flood the screen with
alarms at the slightest disturbance, burying the meaningful one among
dozens of consequences — the alarm flood that makes the root hard to
find. Others use vague or misleading alarm text that names a symptom
poorly or points at the wrong subsystem. Still others fail to alarm on
conditions they should, leaving a fault with no message at all.
Awareness that the alarm system is itself a human-designed artifact, and
an imperfect one, keeps you appropriately skeptical: a flood of alarms
calls for finding the first in time rather than reacting to the loudest;
misleading text calls for verifying the actual condition rather than
trusting the words; a fault with no alarm calls for going online to read
the logic directly, since the machine’s silence does not mean the logic
is not waiting on something. Treating alarms as helpful but fallible
pointers, designed by people who could not anticipate every fault,
rather than as authoritative diagnoses, lets you use the good ones and
see past the poor ones.
A case file: the alarm cascade with a hidden
root
A machine faults and its HMI fills with a dozen active alarms at
once, an intimidating wall of red that seems to indicate catastrophic
failure across many systems. But a flood of simultaneous alarms is
usually a cascade from a single root, not a dozen independent failures,
and the way through it is to find the first alarm in time rather than
reacting to the crowded screen. Opening the alarm history and reading it
in time order, the technician finds that all the alarms fired within a
second or two of one another, in a sequence — and the very first one, a
fraction of a second before the rest, was a loss of a shared utility
that many subsystems depend on. That first alarm is the root; every
alarm after it is a consequence of subsystems reacting to the lost
utility. Acting on the root — restoring the shared utility whose loss
triggered the cascade — clears the entire wall of alarms at once,
because they were all consequences of that single failure. Had the
technician instead started working through the alarms in the order they
appeared on the screen, or tackled the most alarming-sounding one, they
would have chased consequences while the root sat unaddressed. The case
makes concrete the discipline for alarm floods: a screen full of
simultaneous alarms is a cascade to be traced to its root by finding the
earliest alarm in the timestamped history, and addressing that root
clears the consequences, whereas reacting to the flood itself scatters
effort across symptoms of a single underlying cause.