VFD Fault Codes: Complete Guide to Diagnosing and Fixing Them

A variable frequency drive (VFD) trips for a reason. The fault code on the keypad isn’t a random inconvenience.

It’s the drive telling you exactly which parameter crossed a safety threshold in real time before something more expensive failed.

The problem is that every manufacturer labels that information differently, and a technician standing in front of a tripped drive at 2 a.m. doesn’t have time to dig through a 300-page manual.

This guide breaks down the fault codes that show up across almost every VFD brand: Allen-Bradley/Rockwell, ABB, Danfoss, Siemens, Yaskawa, and Schneider.

What actually causes them and the troubleshooting sequence that resolves them fastest.

How VFD Fault Codes Work

Every VFD continuously monitors current, voltage, temperature, and drive logic. When a measured value exceeds a programmed limit, the drive’s microprocessor interrupts output switching (usually within microseconds) and latches a fault code to protect the power module, the motor, or the mechanical load downstream.

This is different from an alarm, which is a warning that a limit is being approached but hasn’t yet forced a shutdown.

Fault codes generally fall into five categories.

  1. Overcurrent / short circuit faults: protect the IGBTs from instantaneous current spikes.
  2. Voltage faults (over/under): protect the DC bus and power supply components.
  3. Thermal faults: protect the drive heatsink or the motor windings
  4. Ground fault/earth fault: detect current leaking to the ground instead of returning through the motor circuit.
  5. Communication and logic faults: flag a broken link between the drive and a PLC, HMI, or fieldbus network

Common VFD Fault Codes and What They Mean

Fault TypeAllen-Bradley (PowerFlex)ABB (ACS series)Danfoss (VLT/FC)Siemens (SINAMICS)Yaskawa (GA500/A1000)Root Cause
OvercurrentF002 / OverCurrent2310 OVERCURRENTAlarm 13F30001oCCurrent exceeds hardware trip limit
Overvoltage (DC bus)F004 / DC Bus Overvolt3210 DC OVERVOLTAlarm 7F30002oVThe motor is regenerating faster than bus can absorb
UndervoltageF008 / DC Bus Undervolt3220 DC UNDERVOLTAlarm 4F30003LV / Uv1Input power sag or phase loss
Ground FaultF007 / Ground Fault2330 EARTH FAULTAlarm 14F30021GFCurrent path to ground, often insulation breakdown
Motor OverloadF007 / F1222130 MOT OVERTEMPAlarm 16F07011oL1 / oL2Sustained current above motor’s thermal rating
Drive OvertempF012 / Heatsink OvrTmp4210 IGBT OVERTEMPAlarm 29F30004oHHeatsink or ambient temperature too high
Short CircuitF070 / Phase U/V/W Short2340 SHORT CIRCUITAlarm 16F30022SCDirect phase-to-phase or phase-to-ground short
Input Phase LossF003 / Input Phase LossAlarm 33F30011PFOne incoming supply phase missing or unbalanced
Output Phase LossF005 / Output Phase Loss2312Alarm 30F30012LFOpen motor lead or motor winding failure
Comm FaultF081 / Comm LossAlarm 46F08501CELost link to PLC/HMI/fieldbus

Exact codes vary by firmware version. Always confirm against your specific drive’s fault table, but the underlying causes below apply almost universally.

How to Fix Each VFD Fault

Overcurrent Fault

This is the most frequent VFD trip, and it’s rarely the drive itself that’s at fault.

  • Check for a mechanical jam, seized bearing, or blocked fan/pump impeller that’s forcing the motor to draw excess current on startup
  • Verify the drive’s acceleration ramp isn’t too aggressive for the load’s inertia. A load that can’t spin up fast enough pulls current the drive interprets as a fault
  • Confirm motor nameplate current matches the drive’s motor parameter settings; an undersized motor parameter will trip on normal load current
  • Inspect motor cabling for a phase-to-phase short or damaged insulation using a megohmmeter

Overvoltage Fault (DC Bus)

Overvoltage almost always happens during deceleration, when a spinning motor with high inertia feeds energy back into the drive faster than the DC bus can dissipate it.

  • Extend the deceleration time (ramp-down) so the load slows more gradually.
  • Add or verify a braking resistor and confirm the dynamic braking parameter is enabled.
  • Check incoming line voltage isn’t running high, especially on lightly loaded three-phase feeders.
  • For fan and pump loads, enable the drive’s built-in flying-start or ride-through function instead of a hard stop.

Undervoltage Fault

  • Measure incoming supply voltage under load; a sagging feeder, undersized transformer, or long conductor run causes voltage drop.
  • Check for a loose or corroded terminal connection on the input side.
  • Look for other large loads (welders, compressors) starting on the same circuit and dragging voltage down momentarily.
  • If undervoltage trips correlate with utility events, consider a line reactor or UPS on the control power.

Ground Fault

  • Disconnect the motor and megger each phase to ground; a reading under 1 MΩ generally indicates winding insulation breakdown.
  • Inspect motor cable for chafed insulation where it passes through conduit fittings or panel knockouts.
  • Check for moisture intrusion in the motor junction box, especially on outdoor or washdown applications.
  • Rule out the drive itself by testing with a known-good motor if the fault persists with everything else isolated.

Motor Overload / Thermal Fault

  • Confirm the motor’s full-load amps (FLA) match what’s programmed in the drive’s motor overload parameter.
  • Check for a mechanical binding condition making the motor work harder than the process requires.
  • Verify motor cooling isn’t obstructed. A dirty or blocked motor fan shroud raises winding temperature under normal current.
  • On variable torque loads at low speed, confirm the motor is rated for the reduced cooling that comes with low-speed continuous operation.

Drive Overtemperature

  • Check that the panel or enclosure ventilation is functioning. A failed enclosure fan is one of the most common causes.
  • Clean the drive’s heatsink fins and internal fan; dust buildup is a frequent culprit in industrial environments.
  • Confirm ambient temperature around the drive is within the manufacturer’s rated range.
  • Verify the drive isn’t derated for altitude or enclosure type but is installed without accounting for that derating.

Phase Loss (Input or Output)

  • For input phase loss, check upstream fuses, circuit breakers, and contactor contacts for one open leg.
  • For output phase loss, check motor cable continuity conductor-by-conductor and inspect the motor terminal box.
  • Measure phase-to-phase voltage balance; more than a 2% imbalance across phases warrants investigation upstream.

Communication Fault

  • Verify network cabling, terminating resistors, and grounding on the fieldbus (Modbus, EtherNet/IP, Profinet, etc.).
  • Confirm the drive’s node address or IP configuration matches what the PLC program expects.
  • Check for electrical noise coupling into communication cable runs routed alongside motor power cables.
  • Reset the drive’s communication watchdog timeout if brief PLC scan delays are triggering nuisance trips.

General Troubleshooting Sequence

When you don’t yet know which category a fault falls into, work through it in this order:

  1. Record the exact fault code and any fault history log before clearing it. Most drives store the last several faults with timestamps, which helps spot patterns.
  2. Check drive status LEDs and display for supplementary alarm codes that may have preceded the trip.
  3. Isolate the motor from the drive and test motor insulation resistance and winding continuity independently.
  4. Verify incoming power quality, voltage, phase balance, and frequency before assuming the drive itself has failed.
  5. Review recent changes. A fault appearing right after a parameter change, firmware update, or mechanical modification points straight to the cause.
  6. Clear the fault and monitor drive parameters (current, DC bus voltage, temperature) in real time on the next run if the drive supports live monitoring.

Preventing Repeat VFD Faults

Most recurring VFD faults trace back to preventable maintenance gaps rather than drive defects.

  • Keep enclosure filters and drive heatsinks clean on a scheduled interval, not reactively
  • Torque-check power terminals annually. Loose connections cause both overcurrent and overtemperature faults.
  • Re-verify motor parameters any time a motor is swapped or rewound.
  • Log fault history over time; a drive that faults intermittently under the same conditions usually has a mechanical or electrical root cause, not a drive defect.
vfd

FAQ

What does it mean when a VFD keeps faulting after a reset?

A fault that returns immediately after reset almost always indicates the underlying condition (short circuit, ground fault, or blocked mechanical load) is still present rather than being a nuisance trip. Don’t keep resetting and running. Isolate the cause first.

Can a bad VFD fault code damage the motor?

The fault code itself is a protective response, not the cause of damage. The condition that triggers it, sustained overcurrent, ground fault, or overtemperature, is what can damage windings if the drive doesn’t trip in time or if faults are repeatedly forced past their protective limit.

Is an overvoltage fault the drive’s fault or the motor’s?

Neither, usually. Overvoltage is almost always caused by regenerative energy during deceleration exceeding what the DC bus and braking system can absorb, a ramp-time or braking-resistor sizing issue, not a component failure.

Do all VFD brands use the same fault code numbers?

No. Fault code numbering is brand- and firmware-specific, though the underlying fault categories (overcurrent, overvoltage, ground fault, overload, thermal) are standard across the industry. Always cross-reference the specific drive’s fault table.

PLC Not Communicating? Fixes by Protocol

You cycle power, check the cables, and stare at a red or blinking status LED that refuses to turn green.

A PLC communication fault is one of the most common and most misdiagnosed problems on a plant floor, because “PLC not communicating” isn’t one failure.

It’s a symptom that five completely different protocols can produce for five completely different reasons.

This guide walks through the most common industrial protocols one at a time: EtherNet/IP, Modbus TCP, Modbus RTU (serial), PROFINET, PROFIBUS DP, DeviceNet/CANopen, and MQTT with the specific checks and fixes that apply to each.

If you already know which protocol you’re dealing with, jump straight to that section. If you’re not sure, start with the quick diagnostic table below.

Quick Diagnostic: Which Protocol Am I Troubleshooting?

SymptomLikely ProtocolWhere to Look First
The status LED shows solid red, RSLogix/Studio 5000 shows “Rack Fault.”EtherNet/IPIP address conflict, switch port, module keying
Modbus Poll or SCADA shows “Timeout” over EthernetModbus TCPPort 502 blocked, wrong unit ID, gateway config
RS-485 network with intermittent garbage dataModbus RTUTermination resistors, baud rate mismatch, wiring polarity
Siemens TIA Portal shows device grayed out, “no connection.”PROFINETDevice name not assigned, VLAN/switch misconfigured
Bus fault LED (BF) solid or flashing redPROFIBUS DPTermination, address conflict, cable length/segment count
Node missing from scan list, MAC ID conflictDeviceNet / CANopenBus power drop, terminating resistors, duplicate MAC ID
The broker shows client disconnected, no telemetry in the dashboard.MQTTBroker reachability, TLS/cert mismatch, QoS/keep-alive settings

With that map in hand, here’s how to actually fix each one.

EtherNet/IP: The Rockwell/Allen-Bradley Standard

EtherNet/IP problems are rarely about the protocol itself. They’re about the Ethernet infrastructure underneath it or about how the PLC’s I/O tree is configured.

Start with the physical and IP layer.

  • Confirm the PLC, the switch port, and the remote I/O module all show link/activity lights. A dead link light means the cable, port, or NIC is the problem, not the logic.
  • Ping the device from a laptop on the same subnet before touching the PLC project. If the ping fails, you have a network problem, not a PLC problem.
  • Check for duplicate IP addresses. This is the single most common EtherNet/IP fault, especially after someone swaps in a spare drive or I/O module without reconfiguring its address first.

Then check the logical layer.

  • In Studio 5000 or RSLogix, open the I/O configuration tree and look for a yellow triangle or red X next to the module. A “Connection Faulted” message usually points to a mismatch between the configured module and the physical module: wrong catalog number, wrong firmware revision, or wrong electronic keying.
  • If you’re bridging through a managed switch, verify multicast traffic isn’t being filtered. EtherNet/IP I/O messaging is often multicast by default, and some switches with IGMP snooping misconfigured will silently drop it.
  • For remote I/O racks, confirm the Requested Packet Interval (RPI) isn’t set so aggressively that the network can’t keep up, which shows up as intermittent, not permanent, faults.

Modbus TCP: Simple Protocol, Simple Failure Points

Modbus TCP is one of the easiest protocols to troubleshoot because it has so few moving parts, which also means when it fails, the cause is usually obvious once you know where to look.

Port 502 blocked

Modbus TCP communicates over TCP port 502. Firewalls, especially on IT-managed VLANs, block it by default. Confirm with a simple telnet or port-scan test from a laptop on the same segment.

Wrong Unit ID / Slave ID

Even on a TCP network, most Modbus TCP devices still expect a unit identifier field carried over from the RTU legacy.

If your master is sending Unit ID 1 and the device expects 0 or 247, you’ll get a connection with no data.

Byte order (endianness) mismatches

Communication can succeed while the data looks like garbage. This is almost always a big-endian vs. little-endian register-swap issue between the master and slave, not a wiring or network fault.

Gateway device

Serial-to-Ethernet Modbus bridges are a frequent hidden point of failure. If the gateway’s serial-side baud rate doesn’t match the downstream RTU devices, the TCP side will connect fine while every read request times out.

Modbus RTU (Serial): It’s Almost Always the Physical Layer

If you’re troubleshooting Modbus RTU over RS-485, resist the urge to start in software. Serial bus problems are overwhelmingly physical.

Termination resistors

RS-485 requires 120-ohm termination at each end of the bus, not at every device. A daisy-chained network with termination in the middle, at every drop, or nowhere at all will produce reflections that show up as intermittent CRC errors.

A/B polarity

Reversed A (+) and B (−) wiring between even one device and the rest of the bus can corrupt data for the whole segment. Check polarity device by device if the fault is intermittent rather than total.

Baud rate, parity, and stop bits must match exactly

All of them must match exactly across every device on the bus. A single device left at factory defaults (often 9600, even parity) on a bus configured for 19200, no parity, will jam communication for everyone.

Bus length and device count

RS-485 supports up to 32 unit loads and roughly 1200 meters at low baud rates, but both cable quality and baud rate reduce that in practice. If you added several devices at the end of a long run, that’s the first thing to test.

Ground loops

A shared reference (common) conductor is required on most RS-485 networks. Without it, voltage differences between remote grounding points can corrupt or completely block communication, especially over long distances or between buildings.

PROFINET: Device Names Come Before IP Addresses

PROFINET is Ethernet-based like EtherNet/IP, but Siemens’ architecture adds a layer that trips up engineers coming from other platforms: the device name.

Device name mismatch

Unlike most Ethernet protocols, PROFINET devices are identified first by a configured device name (assigned via TIA Portal or PROFINET), not by IP address.

A device with the wrong name or no name assigned at all will never establish a connection, even if its IP address is correct.

Topology mismatch

If your project defines a specific network topology (which port connects to which neighbor) and the physical wiring doesn’t match it, TIA Portal will flag a configuration fault even though the device is reachable.

VLAN and switch settings

PROFINET’s real-time classes (RT and IRT) are sensitive to switch configuration. Non-PROFINET-certified switches, or ones with QoS/priority tagging disabled, can introduce enough jitter to break IRT communication while RT and standard TCP/IP traffic still work.

GSD file version

For third-party devices, confirm the GSD (device description) file loaded in TIA Portal matches the actual firmware version on the device.

A version mismatch causes the device to appear in the project but refuse to go into data exchange.

PROFIBUS DP: The Classic Bus-Fault Checklist

If you’re still running PROFIBUS DP, the fault-finding process hasn’t changed much in twenty years, and that’s a good thing, because it’s well understood.

Termination at both physical ends only

Like RS-485-based Modbus, PROFIBUS needs 220-ohm termination active at exactly the two ends of the bus segment, with power supplied to the termination network (most PROFIBUS connectors have a switch for this).

Address conflicts

Every node needs a unique station address (0–126, with 126 reserved). A duplicate address will typically fault the entire segment, not just the conflicting node.

Segment length vs. baud rate

Maximum cable length drops sharply as baud rate increases. 1200 meters at 93.75 kbit/s but only 100 meters at 12 Mbit/s.

If someone increased the baud rate for performance without checking segment length, that’s a likely culprit.

Repeaters between segments

More than 32 stations per segment requires a repeater. Each repeater also counts against the total propagation delay budget, so a bus with several repeaters can suffer timing faults that don’t appear on a bench test.

Cable damage and connector quality

PROFIBUS’s purple cable is a shielded twisted pair; crushed cable, poor shield grounding at connectors, or unofficial connectors (not meeting the PROFIBUS spec) are common intermittent-fault sources.

DeviceNet and CANopen: Check the Bus Power Before Anything Else

Both protocols run on a CAN physical layer, and both share a failure mode that catches people off guard: DeviceNet carries power (24V) on the same cable as data.

Bus power drop

On long DeviceNet trunks with many nodes, voltage can sag below the minimum at the far end even though it reads fine at the power tap. Measure voltage at the node reporting the fault, not just at the source.

Duplicate MAC ID

Every node on a DeviceNet or CANopen network needs a unique MAC ID (0–63). A duplicate ID will typically prevent both conflicting nodes from going online, and some scanners report this as a generic “device not found” rather than a clear conflict message.

Termination resistors (121 ohms for DeviceNet)

At both physical ends of the trunk line, the same principle as RS-485 and PROFIBUS, different resistor value.

Baud rate consistency

All nodes must match (125k, 250k, or 500k kbit/s for DeviceNet). A single node left at a different rate will appear completely offline rather than producing errors.

EDS file mismatches

Similar to PROFINET’s GSD issue, an outdated electronic data sheet in the scanner configuration can prevent a device from being recognized even when it’s electrically present on the bus.

MQTT: The IIoT Layer, Not the Control Layer

MQTT increasingly sits alongside traditional fieldbus and Ethernet protocols for IIoT dashboards, historian feeds, and cloud connectivity, and its failure modes look nothing like the others above, because there’s no fixed master-slave polling relationship.

Broker reachability

Confirm the PLC or edge gateway can actually reach the broker’s IP/hostname and port (1883 for unencrypted, 8883 for TLS). Corporate firewalls frequently block outbound MQTT by default.

TLS/certificate issues

If the broker requires TLS and the client’s certificate is expired, self-signed without being trusted, or simply not loaded, the connection will fail silently in many PLC MQTT client implementations rather than throwing a clear error.

Client ID conflicts

MQTT brokers disconnect the older session when a new client connects with the same client ID.

If two PLCs or gateways were configured with an identical client ID (common after cloning a project), they’ll repeatedly kick each other offline.

QoS and keep-alive mismatches

A keep-alive interval set too aggressively for the network’s latency (common over cellular or VPN links) causes the broker to drop the client as unresponsive even though the device is still running.

Topic and payload structure

Communication can succeed at the transport level while no data appears on a dashboard. Check that the topic strings and JSON payload structure match exactly what the subscriber (Node-RED, historian, cloud service) expects.

General Troubleshooting Order That Applies to Every Protocol

Regardless of which protocol you’re chasing, work from the physical layer up:

  1. Power and physical connection: Is the device actually powered, and is the cable seated and undamaged?
  2. Physical layer settings, termination, baud rate, polarity, or link speed/duplex for Ethernet-based protocols.
  3. Addressing, IP address, device name, station address, or MAC ID checked for conflicts.
  4. Logical configuration, module keying, GSD/EDS files, topology, or client IDs matching what’s actually deployed.
  5. Data interpretation, byte order, scaling, and payload structure, once communication itself is confirmed.

Skipping straight to step 5, assuming the logic or SCADA tags are wrong, is the most common way engineers waste an afternoon on what turns out to be a missing termination resistor.

FAQ

Why does my PLC show communication is established but the data looks wrong?

This almost always points to a data-interpretation issue rather than a communication fault, most commonly byte-order (endianness) mismatches on Modbus, or an incorrect scaling factor applied on one side of the link.

Can two different protocols run on the same physical Ethernet cable?

Yes. EtherNet/IP, PROFINET, Modbus TCP, and MQTT can all share the same physical network, but they don’t interoperate with each other directly.

A device speaking one protocol can’t be read by a master speaking another without a gateway or protocol converter in between.

Is a red status LED always a communication fault?

Not necessarily. Many PLCs and I/O modules use the same LED, or a related one, to indicate other faults (I/O module mismatch, firmware fault, internal diagnostic error). Always check the manufacturer’s LED status table before assuming it’s strictly a comms issue.

How do I know if the problem is the cable or the device?

Swap in a known-good cable of the same type first. It’s the fastest, cheapest elimination test. If the fault follows the cable, it’s the cable; if it follows the device, move to addressing and configuration checks.