Overload, Comms, and Nuisance Faults

This chapter covers three further important fault types: motor
overload (distinct from the instantaneous overcurrent), communication
and reference faults, and the nuisance trips that plague drive users.
These faults — sustained overloading, lost communications or references,
and trips that seem to have no real cause — round out the common drive
faults, and understanding them completes the picture of what a drive can
trip on and why.

Motor overload

Motor overload is a fault distinct from the instantaneous
overcurrent: it means the motor has drawn a sustained current above its
rating, which the drive’s overload protection detects over time and
trips on to prevent the motor overheating. Unlike overcurrent (a fast,
large spike), overload is a sustained moderate overcurrent — the motor
working harder than its rating for a period. The causes are those that
make a motor draw sustained excess current: a genuine mechanical
overload (the load too heavy), wrong motor data (the drive mis-judging
the motor’s normal current), reduced cooling at low speed (the motor
overheating at a current it could sustain when better cooled), or
mechanical drag (bearings, misalignment) making the motor work harder.
The drive’s overload protection, modeling the motor’s heating, trips to
protect it. Understanding motor overload — sustained excess current
tripping the overload protection, distinct from instantaneous
overcurrent — directs its diagnosis to the causes of sustained
overcurrent: load, motor data, cooling, and mechanical drag. It
reinforces distinguishing overload (sustained, time-delayed trip) from
overcurrent (instantaneous spike), as they have different causes and
diagnoses. Motor overload leads to checking why the motor draws
sustained excess current — the load, the motor data, the cooling, the
mechanics — to find and address the cause, whether reducing the load,
correcting the motor data, improving cooling, or fixing mechanical drag,
resolving the sustained overcurrent that trips the overload
protection.

Communication and reference faults

Communication and reference faults concern the drive losing its speed
command or its network communication, and they often relate to wiring,
configuration, or noise. A reference fault means the drive lost its
speed reference — the signal telling it how fast to run — which could be
from a broken reference wire, a failed reference source, or (for an
analog reference) a signal problem. A communication fault means the
drive lost its network communication (where it is controlled or
monitored over a network), which could be from a network wiring problem,
a network configuration mismatch, or electrical noise disrupting the
communication. Noise is a common and frustrating cause of both, as the
drive’s own switching noise can disrupt reference signals and
communications if grounding and shielding are inadequate. Understanding
these faults — lost reference or communication, from wiring,
configuration, or noise — directs their diagnosis to the reference and
communication wiring, the configuration, and the grounding and
shielding. It reinforces that communication and reference faults often
stem from wiring problems (broken or noisy connections), configuration
mismatches, or noise, with noise being a particularly common and
difficult cause. Diagnosing these faults involves checking the relevant
wiring and configuration and, crucially, the grounding and shielding
that protect against noise, because a drive that loses its reference or
communication intermittently or erratically may well be suffering noise
interference, pointing to the grounding and shielding as the underlying
cause of these often-puzzling communication and reference faults.

Nuisance trips

Nuisance trips — where the drive trips without a real fault condition
— are a common frustration, and understanding their causes distinguishes
them from genuine faults. A nuisance trip is one where the drive trips
but there is no actual problem with the motor, load, or drive that
warranted it: the trip is spurious. Causes include protection settings
that are too sensitive (tripping on normal conditions), electrical noise
(causing false readings that trigger trips), parameter issues (a setting
causing inappropriate trips), and marginal conditions (the drive
tripping on conditions that are borderline but not truly faulty). The
key to diagnosing a suspected nuisance trip is to determine whether
there is a real fault condition: using the drive’s meters to check
whether, for instance, an overcurrent trip corresponds to a real
overcurrent, or the trip is spurious. If the values are normal but the
drive trips, it is a nuisance trip, pointing to settings, noise, or
configuration; if the values show a real fault condition, it is genuine.
Understanding nuisance trips — spurious trips from over-sensitive
settings, noise, or configuration, distinguished from genuine faults by
checking whether a real fault condition exists — directs their
diagnosis. It reinforces using the drive’s diagnostics to distinguish
nuisance from genuine trips (is there a real fault condition?), and, for
nuisance trips, looking to the settings, noise, and configuration that
cause spurious trips. Nuisance trips are often ultimately noise or
setting problems, and understanding how to identify them — by confirming
the absence of a real fault condition — prevents both the frustration of
unexplained trips and the error of chasing a nonexistent hardware fault,
directing attention instead to the settings, grounding, and
configuration that cause spurious tripping.

The frustration of intermittent faults

Intermittent faults — those that come and go — are among the most
frustrating in drive troubleshooting, and understanding why, and how to
approach them, helps. An intermittent fault does not present
consistently: it trips sometimes and not others, making it hard to
observe, hard to reproduce, and hard to test, because when you look, it
may not be happening. Intermittent faults often have causes that depend
on conditions — temperature, load, timing, electrical noise, a marginal
connection — that vary, so the fault appears only when conditions align.
This makes them puzzling and time-consuming. The approach to
intermittent faults is to use the drive’s fault log (which records the
intermittent trips even when you are not watching), to look for patterns
in when they occur (correlating with conditions), and to suspect the
causes of intermittent faults specifically: noise (which is inherently
intermittent), marginal connections (which fail sometimes), and
condition-dependent factors. Understanding the frustration of
intermittent faults — hard to observe and reproduce, condition-dependent
— and the approach — use the fault log, find patterns, suspect noise and
marginal connections — helps tackle them. It reinforces that
intermittent faults require using the drive’s fault history and
pattern-finding rather than direct observation, and suspecting the
intermittent-by-nature causes like noise and loose connections.
Understanding how to approach intermittent faults — patiently, using the
fault log and patterns, suspecting the characteristic causes — makes
these frustrating faults more tractable, turning the drive’s recorded
history into the means of diagnosing faults that are too intermittent to
catch in the act.

Scenario: the comms fault that was noise

A scenario shows a communication fault traced to noise. A drive
controlled over a network suffered intermittent communication faults —
the network connection dropping occasionally, causing faults — with no
consistent pattern. The network wiring and configuration checked out,
deepening the puzzle. Recognizing that intermittent, erratic
communication problems often stem from noise, the technician examined
the grounding, shielding, and wiring routing. The communication cable,
it turned out, ran alongside the drive’s output power cable and was not
well shielded, so the drive’s switching noise coupled into the
communication wiring, intermittently disrupting the communication and
causing the faults. The fix addressed the noise: separating the
communication cable from the power cable and using properly shielded,
grounded communication cable. This stopped the intermittent
communication faults. This scenario shows a communication fault caused
by noise — the drive’s switching noise coupling into poorly-separated,
poorly-shielded communication wiring. Understanding that noise commonly
causes intermittent communication faults, and that it couples from power
wiring into unshielded control wiring run alongside, explains this: the
communication fault was noise, from the wiring arrangement. It
reinforces suspecting noise when communication faults are intermittent
and the wiring and configuration seem fine, and checking the grounding,
shielding, and wiring separation. The scenario reinforces that many
communication and reference faults are ultimately noise problems,
diagnosed by recognizing the noise signature (intermittent, no config
fault) and tracing it to the wiring, grounding, and shielding — here
poorly separated and shielded communication cable — fixed by proper
wiring separation and shielding.

Verifying a nuisance trip before acting

Before treating a trip as a nuisance trip, verifying that it truly is
one — that no real fault condition exists — is essential, and
understanding this prevents a dangerous error. A nuisance trip is one
with no real underlying fault, but treating a genuine trip as a nuisance
trip — assuming there is no real problem and, say, desensitizing the
protection to stop the tripping — would defeat protection against a real
fault, risking damage. So it is essential to verify, before treating a
trip as nuisance, that no real fault condition exists: using the drive’s
meters to check whether, for instance, an overcurrent trip corresponds
to a real overcurrent, or the values were normal. Only if the values
confirm no real fault condition should the trip be treated as a nuisance
trip (pointing to settings, noise, or configuration). If a real
condition exists, it is a genuine trip to be diagnosed. Understanding
the importance of verifying a nuisance trip — confirming no real fault
condition before treating it as spurious — prevents the error of
defeating protection against a real fault. It reinforces using the
drive’s diagnostics to confirm a trip is truly a nuisance (no real fault
condition) before addressing it as such, because assuming a genuine trip
is a nuisance and desensitizing the protection would leave a real fault
unprotected. Understanding that a nuisance trip must be verified — not
assumed — before acting reinforces confirming the absence of a real
fault condition first, which prevents the dangerous error of treating a
genuine protective trip as a nuisance and thereby defeating protection
against a real and possibly damaging fault.

Distinguishing real from spurious

A consolidating lesson from these faults is the importance of
distinguishing real fault conditions from spurious ones, and recognizing
this frames the approach to overload, communication, and nuisance
faults. Overload requires distinguishing a real sustained overcurrent
(genuine overload, to be addressed) from a mis-set overload protection
(nuisance). Communication and reference faults require distinguishing
real communication/wiring problems from noise-induced spurious ones.
Nuisance faults, by definition, require distinguishing spurious trips
(no real fault condition) from genuine ones. So across these faults runs
the theme of determining whether a real fault condition exists, using
the drive’s diagnostics to check. This distinction — real versus
spurious — is essential to addressing these faults correctly: real
conditions to be fixed, spurious ones traced to settings, noise, or
configuration. Recognizing this consolidating theme frames the approach:
verify whether a real fault condition exists before acting. It
reinforces using the drive’s diagnostics to distinguish real from
spurious across these faults, because treating one as the other leads to
error (defeating protection against a real fault, or chasing a
nonexistent hardware fault). Understanding the distinction between real
and spurious fault conditions as the consolidating theme of overload,
communication, and nuisance faults reinforces verifying whether a real
condition exists — using the drive’s diagnostics — before addressing
these faults, which ensures real faults are fixed and spurious ones
traced to their true causes (settings, noise, configuration), rather
than the two being confused to the detriment of the diagnosis and the
drive’s protection.