Analog outputs work like analog inputs in reverse: the PLC commands a
value and the card produces a proportional signal, most often a 4–20 mA
or 0–10 V reference to a variable frequency drive (VFD) or a valve
positioner. Troubleshooting mirrors analog inputs — separate the command
from the signal from the receiving device.
VFD speed references
When a drive runs at the wrong speed or not at all, determine first
whether the PLC is sending the reference it should. Read the commanded
value in the program, then measure the actual analog output signal at
the terminals, then read what the drive reports as its received
reference on its own keypad or in its parameters. Wherever the value
first goes wrong is where to focus. Many drives display the reference
they are receiving, which makes this a quick three-point check. Remember
that a drive often needs both a run command (usually digital) and a
speed reference (analog) — a missing run permissive looks like a dead
reference but is not.
Valve positioners
A modulating valve driven by a 4–20 mA output should track the
commanded position. If it does not, inject a known current directly to
the positioner to see whether the valve responds — this separates a
fault in the PLC output from a fault in the positioner or valve. A valve
that responds to an injected signal but not to the PLC points back at
the output card or wiring; one that ignores the injected signal too is
mechanical or a positioner fault.
The three-point check for drive speed
When a drive runs at the wrong speed, a simple three-point check
localizes the fault fast because it follows the reference from origin to
destination. Point one: what value is the program commanding for the
analog output? Read it online. Point two: what signal is actually
present at the analog output terminals? Meter it, or read loop current
with a calibrator. Point three: what reference does the drive report
receiving, on its own keypad or in its parameters? The place where these
three first disagree is the fault. Program commands 50% but the output
terminal reads 0 mA? The card or its configuration is at fault. Terminal
reads correct current but the drive reports a different reference?
Wiring, drive input configuration, or scaling on the drive side. This
ordered comparison turns a vague speed problem into a located one.
Run command versus speed reference
A frequent and confusing situation: the drive will not run, and
everything about the speed reference checks out. The trap is that most
drives need two independent things to run — a run command, usually a
digital signal or a network command, and a speed reference, usually the
analog signal. A perfect speed reference with a missing run command
produces a drive sitting idle at a healthy reference, which looks like a
reference fault but is not. When a drive will not run, confirm both the
run permissive and the speed reference before diving deep into either.
Many lost hours trace to a technician perfecting a speed signal while
the run command quietly sat missing.
Reading the drive’s own diagnostics
Drives are intelligent devices with their own fault displays, and
reading them saves guesswork. A drive fault code names what the drive
detected — an overcurrent, an overvoltage, a lost reference, a
communication timeout, a motor overload — and points you at the cause
far more directly than treating the drive as a black box. When a driven
axis misbehaves, read the drive’s fault before the PLC’s, because the
drive is closest to the motor and often sees the real problem first. The
PLC may only report that the drive faulted; the drive itself reports
why.
A case file: the drive stuck at minimum speed
A conveyor drive runs but crawls at minimum speed regardless of the
speed the program commands. Following the three-point check, the
technician reads the program commanding 75%, meters the analog output
terminals and finds only a tiny current far below what 75% should
produce, and so localizes the fault between the program’s command and
the physical output — the analog output card or its configuration.
Checking the card’s configuration reveals its output range was set
incorrectly after a recent parts swap, so the card produced almost
nothing across the whole commanded range. Correcting the range restores
proportional control. Had the technician instead found the correct
current at the terminals but the drive still crawling, the fault would
have been on the drive’s side — its input scaling or configuration — and
had the drive reported the right reference while still crawling, the
fault would have been a drive parameter limiting speed. The three-point
check placed the fault precisely by finding where the value first went
wrong.
When the reference is a network value
Increasingly, drives receive their speed reference not as an analog
signal but as a value over a network — EtherNet/IP or PROFINET — which
changes the troubleshooting. There is no analog terminal to meter;
instead the reference travels in the network data exchanged between
controller and drive. The equivalent checks become: what value is the
program placing in the output data to the drive, and what value does the
drive report receiving in its parameters or display? A mismatch points
at the network data mapping or a communication problem rather than at
wiring. And because the reference and often the run command both travel
over the network, a communication fault can remove both at once,
stopping the drive in a way that looks like a drive failure but is
really a lost connection. When a network-referenced drive misbehaves,
check the communication health and the data mapping alongside the
drive’s own parameters.
Understanding what the drive adds
A variable frequency drive is a sophisticated device sitting between
the PLC’s simple reference and the motor, and appreciating what it does
clarifies where drive-related faults live. The drive takes a speed
reference and translates it into the varying voltage and frequency that
actually control the motor, while also protecting the motor and itself,
monitoring current, and often providing its own diagnostics. This means
a fault in a driven axis can lie in the PLC’s reference, in the network
or wiring carrying it, in the drive’s configuration and parameters, in
the drive’s power section, or in the motor — a longer chain than a
simple output. The drive’s own fault display is the key to navigating
this chain, because the drive sees the motor directly and reports what
it detects: an overcurrent suggests a motor or load problem, an
overvoltage often relates to deceleration or supply, a lost reference
points back toward the PLC, a communication fault points at the network.
Reading the drive’s fault first, before assuming the PLC or the motor,
uses the drive’s own view of the problem to point at the right part of a
longer-than-usual fault chain.
A case file: the reference that never arrived
A pump driven by a VFD will not run, and the operator reports the
drive is ‘dead,’ though its display is lit and shows no fault.
Investigating, the technician finds the drive is receiving a zero speed
reference — it is not dead but idle, correctly holding zero speed
because that is what it has been told. Following the reference back, the
program is commanding a proper speed, but the analog output carrying it
reads zero at the terminals. The fault lies between the program and the
output terminals, in the output card, and proves to be a wiring fault
where the analog output’s connection had been disturbed during nearby
work. The drive was healthy throughout, doing exactly what a zero
reference demands. The case illustrates a common misread: a drive
sitting idle at zero speed looks ‘dead’ but is often simply receiving no
reference, and the fix lies in restoring the reference — somewhere
between the program and the drive’s input — rather than in the drive
itself, which is faithfully executing the zero it was given.
A case file: the two-part drive fault
A drive will not run, and the technician, remembering that a drive
typically needs both a run command and a speed reference, checks both
rather than fixating on one. The speed reference checks out — the
program commands a speed, the analog output produces the corresponding
signal, the drive reports receiving it. Yet the drive sits idle, which
would be baffling if the reference were the whole story. Turning to the
run command, the technician finds it missing: the digital run permissive
the drive needs to actually run is not being asserted, so the drive
holds at a valid reference it has been given permission to receive but
not to act on. The fault was never in the reference at all; it was in
the separate run command, and a technician who checked only the
reference — which was perfect — would have been stuck, unable to explain
why a drive with a good reference would not run. Finding and restoring
the missing run permissive starts the drive. The case makes concrete a
trap specific to drives: because they require both a run command and a
speed reference as independent signals, a drive can have a flawless
reference and still sit idle for want of the run command, and
troubleshooting only the reference leaves the real fault — the missing
run permissive — undiscovered. Checking both the run command and the
speed reference whenever a drive will not run, rather than assuming the
problem lies in the reference, is what catches this common two-part
fault and prevents the frustrating experience of perfecting a reference
that was never the problem.