Intermittent Faults: The Hardest Problems

Every technician dreads the fault that will not stay put — the
machine that runs perfectly while you watch and fails the moment you
leave. Intermittent faults are hard because the core method,
reproduce-and-measure, is exactly what you cannot reliably do. Success
comes from changing the game: instead of catching the fault live, you
capture evidence and narrow the field by pattern.

Capture instead of catch

Your best allies are the timestamped logs you already met: the
controller’s fault log or diagnostic buffer and the HMI alarm history.
Together they answer when the fault happens, which turns a random
annoyance into a pattern. Does it fail at the same time of day? After
the machine warms up? When a nearby high-power machine cycles? On a
particular product? Every pattern eliminates whole categories of
cause.

The usual suspects

Most intermittent electrical faults trace back to a connection or an
environmental influence. A loose or vibrating terminal makes and breaks
contact with machine motion. A wire chafed against a sharp edge shorts
only when the cable flexes a certain way. Thermal expansion opens a
marginal joint once the panel heats up. Electromagnetic interference
from a variable frequency drive or a welder corrupts a signal only while
that equipment runs. Moisture or coolant ingress bridges contacts
intermittently. Notice that almost none of these are the PLC itself —
the controller is usually the reliable part reporting an unreliable
field.

16. Pull the logs and establish when it happens. Correlate with time,
    temperature, nearby equipment, and product.

17. With the machine safely stopped, physically wiggle and tug
    suspect wiring and connectors while watching the input in software — you
    can often provoke a loose connection by hand.

18. Check terminal tightness in the implicated circuit; look for
    discoloration or corrosion that betrays a bad joint.

19. Consider environment: route signal wiring away from drive cables,
    verify shields are grounded at one end, and look for heat and moisture
    near the failure point.

20. If a specific module or channel is implicated by the logs, try a
    known-good spare to confirm or exclude the hardware.

Provocation testing: making the fault appear

When a fault is intermittent, one of the most effective techniques is
controlled provocation — deliberately trying to trigger the fault while
you watch, under safe conditions. If you suspect a loose connection,
gently wiggle and tug the suspect wiring and connectors while monitoring
the relevant signal online; a signal that flickers as you move a
specific wire has just confessed. If you suspect thermal effects, a heat
source or a freeze spray applied carefully to suspect components can
bring on or clear the fault, pinpointing the temperature-sensitive part.
If you suspect vibration, running the machine or tapping components can
reproduce it. Provocation converts an intermittent fault into a
temporarily reproducible one, and reproducibility is what
troubleshooting needs. The essential discipline is safety: provocation
must never create a hazard, and moving live wiring demands appropriate
precautions.

A case file: the fault that waited for the sun

A machine near a large roll-up door faults intermittently, and the
alarm history reveals the pattern: the faults cluster in the afternoon.
Nothing in the control system cares about the time of day, so what
changes in the afternoon? The technician realizes the afternoon sun
falls directly on a photoelectric sensor through the open door, and the
sensor is being blinded by direct sunlight, momentarily losing its
target. The fix is a simple shade, but the solution came entirely from
the timestamp pattern in the alarm history pointing at an environmental
variable no schematic would ever show. Intermittent faults often have
causes outside the control system entirely — light, heat, vibration,
moisture, nearby equipment — and the log’s timestamps are what connect
the fault to its hidden environmental trigger.

Building a record when you cannot catch it live

The hardest intermittent faults resist even provocation, appearing
too rarely and unpredictably to catch. Here the strategy shifts to
instrumentation and patience: set up the system to capture evidence when
the fault occurs even though you are not present. The controller’s fault
log and HMI alarm history already do this to a degree. Beyond them, some
controllers can be set to capture a snapshot of relevant values when a
specific condition occurs, and a simple data log of suspect signals over
time can reveal a transient dip or spike that coincides with the fault.
The mindset is to stop trying to be present at the failure and instead
ensure the failure leaves a trace you can read afterward. Each captured
occurrence adds to a record, and the pattern that solves the fault
usually emerges from that accumulating record rather than from a single
lucky observation.

A case file: the fault that rode the forklift

A machine faults briefly and unpredictably, a few times a week, with
no pattern the technician can find in time of day, temperature, or
product. The breakthrough comes from a wider observation: the faults
coincide with a forklift passing a particular spot nearby. The
forklift’s electrical system, or the vibration of its passage over a
floor joint, was coupling into a marginal connection in the machine — a
loose terminal that a jolt of vibration momentarily opened, or
electrical noise the forklift generated that a poorly shielded signal
picked up. The cause lay entirely outside the machine, in its
environment, which is why no amount of studying the machine’s own
operation revealed it. Intermittent faults frequently have external
triggers — passing equipment, nearby electrical loads, building
services, weather — and solving them sometimes requires widening your
attention beyond the machine to everything happening around it when the
fault strikes. The log’s timestamps, correlated with events in the
surrounding environment, are what expose these outside triggers.

The discipline of the single variable

Intermittent faults punish impatience more than any other kind, and
the specific impatience to guard against is changing several things at
once. The urge is understandable: the fault is rare and frustrating, so
you tighten every terminal, reroute several cables, and replace a
suspect module all in one visit, hoping something works. But if the
fault then stays away, you have learned nothing about which change
mattered, and you have possibly introduced new variables. Worse, if it
returns, you have exhausted several theories at once and are left with
nothing to try. The discipline is to change one variable, then observe
long enough to know whether it helped, before changing the next. This
feels slower, and in the moment it is, but for a fault whose whole
difficulty is establishing cause and effect across rare occurrences,
preserving a clean one-change-at-a-time record is the only path that
reliably converges on the real cause.

Instrumenting a fault you cannot catch

For the hardest intermittent faults — too rare and unpredictable to
catch live or provoke on demand — the decisive move is to instrument the
system so the fault records its own occurrence, and understanding the
options here expands what you can solve. The controller’s fault log and
HMI alarm history are the baseline, capturing timestamped occurrences
automatically. Beyond them, some controllers can capture a snapshot of
chosen values when a specific trigger condition occurs, freezing the
state of the machine at the moment of fault for later study. A data log
recording suspect signals continuously over time can reveal a brief dip,
spike, or dropout that coincides with the fault, exposing a transient
that real-time watching would miss because no one can watch continuously
for days. The common thread is shifting from trying to be present at a
rare failure to arranging for the failure to leave a detailed trace you
can examine afterward. Each captured occurrence, with its surrounding
data, adds evidence, and the accumulating record is what eventually
reveals the cause of a fault too elusive to catch in the act. This
instrument-and-wait approach is often the only viable path for the
rarest intermittent faults, and knowing it exists keeps you from either
giving up or wasting days waiting at the machine.

The psychology of the intermittent fault

Intermittent faults test temperament as much as technique, and
managing your own response to them is part of solving them. They are
frustrating precisely because they defeat the normal satisfaction of
reproduce-and-fix, appearing and vanishing on their own schedule,
seeming to mock each attempt when they stay away just long enough to
suggest the last change worked before returning. This frustration drives
the errors that make them worse: changing many things at once out of
impatience, declaring victory prematurely when the fault is merely
between occurrences, or abandoning the method for desperate guessing.
The discipline that solves intermittent faults is largely emotional —
the patience to change one thing at a time, the rigor to wait long
enough to judge whether it helped, the humility to keep documenting
rather than lunging at a fix, and the steadiness to keep trusting the
method through the fault’s taunting rhythm. Recognizing that the
intermittent fault is testing your patience as much as your knowledge,
and deliberately holding to the disciplined slow approach against the
urge to thrash, is what carries you to the cause. The technicians who
solve these faults are not those who care least but those who best
manage the frustration of caring while the fault refuses to
cooperate.

A structured summary of the intermittent-fault
approach

The approach to intermittent faults, which resist the normal
reproduce-and-fix method, organizes into a coherent strategy built on
capturing evidence and reading patterns rather than catching the fault
live. The foundation is the timestamped record — the controller’s fault
log and the HMI alarm and event history — which turns ‘random’ into
‘patterned’ by revealing when the fault occurs, and thereby whether it
correlates with time, temperature, machine motion, product, or nearby
equipment and building services. When a suspect is identified,
provocation testing — safely wiggling wiring, applying heat or cold,
inducing vibration — attempts to convert the intermittent fault into a
temporarily reproducible one so it can be pinned down. For faults too
rare to catch or provoke, instrumentation takes over: snapshot captures
on a trigger condition and continuous data logs of suspect signals
arrange for the fault to record its own occurrence in detail for later
study. Throughout, two disciplines are decisive: changing only one
variable at a time so cause and effect stay legible across rare
occurrences, and using the log after a repair to confirm the fault has
genuinely stopped recurring rather than merely gone quiet. And
underlying the technical strategy is the temperamental one — the
patience and rigor to hold to this slow, disciplined approach against
the frustration that intermittent faults provoke. Together these turn
the hardest category of fault from a matter of luck into a methodical,
if slower, investigation that reliably converges on causes that often
lie in a marginal physical connection or an environmental influence
outside the control system entirely.

A case file: the connection found by feel

An intermittent fault resists every attempt to correlate it with
time, temperature, or nearby equipment, appearing at random with no
discernible pattern in the logs. With pattern analysis exhausted, the
technician turns to provocation, suspecting a loose connection somewhere
in the implicated circuit and setting out to find it by physically
disturbing the wiring while watching the relevant signal online. Working
methodically along the circuit, gently wiggling and tugging each
connection and terminal in turn while a colleague watches the signal,
the technician reaches a particular terminal where a light touch makes
the signal flicker — the loose connection, revealed by provocation where
pattern analysis had failed. The terminal, which looked sound to the
eye, had enough looseness to make and break contact under the slightest
disturbance, and in normal operation the ordinary vibration of the
machine was intermittently opening it, producing the random-seeming
fault. Remaking the connection solidly eliminates the fault. The case
demonstrates provocation as the technique that succeeds when pattern
analysis cannot: for an intermittent fault suspected to be a loose
connection, deliberately disturbing the wiring while watching the signal
can provoke the fault on demand and localize it to the exact terminal,
converting an untraceable random fault into a found and fixed one. The
signal flickering under a light touch at one specific terminal is the
confession the technique is designed to elicit, and it pinpoints a loose
connection that visual inspection missed and that pattern analysis could
never have located, since its triggering — ordinary machine vibration —
left no distinctive pattern in time or conditions. Provocation, applied
safely and methodically, is thus a powerful complement to log analysis
for the intermittent faults whose triggers are too diffuse to show as
patterns.