A drive drops off the network, the PLC declares a communication timeout, and the blame rotation begins. Operations blames the drive. Controls blames the switch. IT looks at the switch logs, finds nothing, and blames the drive right back. Meanwhile the fault clears on its own, everything runs for two days, and then it happens again during Thursday’s second shift.
Communication faults occupy a special place in the first-week fault distribution. They account for a modest share of the total, but they consume an outsized share of diagnostic time, because they live on the border between two trades. The maintenance electrician sees a drive fault. The controls engineer sees a network problem. Both are looking at the symptom, and the symptom points away from the cause. In most of these cases the network hardware is innocent, the drive hardware is innocent, and the fault was installed, not manufactured.
What the Fault Actually Means
A communication fault or communication timeout means one thing: the drive stopped hearing from its control source, a PLC, BMS, or SCADA system, for longer than its configured timeout allows. On installations where the drive takes start, stop, and speed reference over EtherNet/IP, PROFINET, Modbus, or BACnet rather than hardwired signals, that silence is an operational emergency, and the drive responds however its loss-of-communication parameter tells it to respond.
The fault code does not say why the messages stopped. That is the diagnostic work, and it sorts into four cause families that cover nearly every first-week case.
Cause One: The Communication Cable Is Living With the Power Cables
This is the most common cause of VFD communication faults, and it is an installation decision, not a network problem. The drive’s PWM output switches hundreds of volts with rise times of 0.1 to 0.5 microseconds, and those transients couple into any nearby conductor. A communication cable running parallel to a motor cable picks up that noise, the noise corrupts packets, the corrupted packets fail their checks, and enough failures in a row become a timeout.
The prevention is separation. Keep communication cables at least 2 inches from 120 volt wiring and at least 4 inches from 480 volt wiring, and treat those as minimums, because the physics rewards distance generously: inductive coupling falls with the square of separation, so doubling from 2 inches to 4 cuts it by 75 percent. Where a communication cable must cross power wiring, cross at 90 degrees. Never share a wireway with motor conductors, shielded or not.
Cable construction matters just as much. Unshielded Ethernet cable is fine in an office and wrong in a drive panel; the missing shield invites exactly the coupling that produces CRC errors, retransmissions, and timeouts. Use shielded Cat5e or Cat6 for EtherNet/IP, industrial-rated cable and connectors for PROFINET, and shielded twisted pair for Modbus RTU with the shield landed at one end. The wider routing discipline lives in the VFD Installation Guide.
Cause Two: The Fault Is Thermal, Not Electrical…more common now…
If communication faults arrive on hot afternoons or under heavy load and clear when the drive cools, stop chasing the network. An overheated drive destabilizes its own microprocessor and communication interface, and the comm fault is just the first symptom of an overtemperature problem: blocked cooling passages, inadequate enclosure ventilation, a failed fan, or a panel design that never had the clearance it needed.
The tell is the pattern. Wiring noise correlates with the drive running and with what the motor is doing. Thermal instability correlates with temperature: time of day, season, load level, and how long the drive has been working. A comm fault that keeps office hours in July is a cooling problem wearing a network costume.
Cause Three: The Configuration Never Matched
Baud rate, node address, data format, timeout values: if the drive and the control system disagree on any of them, the link fails. This is a commissioning error, and it should have been caught during parameter configuration, but it shows up as a first-week fault whenever the communication system was not fully exercised before handoff, which is often.
EtherNet/IP deserves special mention, because it fails politely. The hardware can be perfect and the link healthy, every ping answered, every link light green, while the setup is wrong: the input and output assembly instances configured in the PLC do not match what the drive expects, or the drive’s addressing scheme does not match the scanner’s. The comms work; the conversation does not.
My first test on any suspect setup is a single read of the DC bus voltage. An energized drive’s bus is never perfectly still; even sitting at zero speed it wanders slightly, so a value that updates and breathes proves the cable, the addressing, and the instance mapping in one register. A frozen number tells you that you are reading something, just not the drive. One register, ten seconds, and the diagnosis splits cleanly into a configuration problem or a communication problem before anyone opens a panel.
The timeout setting itself belongs in this family. Every networked drive watches for valid telegrams and trips when the silence exceeds its configured limit, and that limit is a commissioning decision, not a constant of nature. Set it tighter than the network can honor, and PLC scan variation or peak traffic will occasionally exceed the window and hand you a fault with nothing broken anywhere. The rule is that the timeout must exceed the worst-case interval between valid telegrams under full production load, with margin. Defaults vary across protocols and manufacturers from milliseconds to seconds, so verify the number rather than trusting it.
Addressing deserves its own sentences. In industrial environments, give drives static IP addresses. A drive configured for DHCP holds its address only as long as the DHCP server answers; let that server hiccup during a maintenance window and the drive vanishes from the network through no fault of its own. And make every address unique on paper before it is unique on the wire: two devices sharing an IP produce ARP conflicts and intermittent, migrating communication failures that are miserable to catch live. Static addressing plus a documented address register removes two failure modes for the cost of a spreadsheet.
Cause Four: The Termination Resistor That Is Not There
Serial networks like Modbus RTU and PROFIBUS require termination resistors at both ends of the trunk. A missing or misplaced termination causes signal reflections that corrupt data, and the corruption gets worse as network traffic grows, which is why these installations often commission clean and start faulting when the system reaches full production load.
On any intermittent multi-drop serial problem, verify termination first. It is the single most common installation error on these networks, it takes minutes to check, and it is the last thing most people look at because the network worked fine yesterday.
Cause Five: When the Switch Is Guilty, It Is Guilty in Specific Ways
The opening said the network hardware is usually innocent, and it is. But when the switch is the problem, it fails in two recognizable ways, both configuration rather than hardware. Spanning tree protocol left enabled on a simple star topology adds convergence delays the drives never needed, and a topology recalculation can outlast a tightly set comm timeout. Unless the network is an actual ring with redundant paths, spanning tree has no job to do on a drive network. The second is multicast. EtherNet/IP implicit messaging travels as multicast traffic, and a switch without IGMP snooping floods that traffic to every port, loading the network for no benefit. An industrial managed switch with IGMP snooping enabled, and spanning tree reserved for real rings, closes both doors.
These causes are also the cheapest to test. An extended ping to each drive with packet loss logged, and an ARP scan for duplicate addresses, cost nothing and settle in an hour what speculation argues about for a week.
Reading the Pattern: Wiring Problem or Device Problem
Four discriminators separate an installation problem from a hardware one, and they cost nothing but attention. If the fault appears when the drive is running and stops when the drive is stopped, it is wiring. If changing the drive’s carrier frequency changes the symptom, it is wiring. If the trouble began after a new drive was added or after cables were moved, it is wiring. And if the signal or network measures clean at the source but arrives corrupted at the drive, the noise is being coupled in along the path. Only when all four point away from the installation is it time to suspect the switch, the option card, or the drive itself. The full diagnostic sequence for every first-week fault family lives in the VFD Troubleshooting Guide.
One Warning Worth the Whole Article
Many drives carry an RJ45 jack on the front for the removable keypad. It looks exactly like an Ethernet port. It is not. It is a serial port with voltage on its pins, and a laptop patched into it loses its Ethernet controller permanently. The real Ethernet port lives on the communication option card and is labeled as such. Before any cable meets any RJ45 on a drive, read the label. This mistake has ended enough laptops that the warning has earned a permanent place in the book.
The Border Between Two Trades
Communication faults persist because they are nobody’s whole job. The electrician owns the panel, the controls engineer owns the network, and the cable connecting them crosses a boundary on the org chart as well as in the plant. The drive does not care about the org chart. It reports the silence, names its timeout, and waits for someone to look at the path between the two innocent machines.
The routing, shielding, and separation disciplines that prevent these faults are covered in depth in the VFD Installation Guide, and the fault-by-fault diagnostic method belongs to the VFD Troubleshooting Guide. The complete treatment, from cable specification through the loss-of-communication decision, is in Before the First Fault, and the VFD training course puts your team in front of live drives until the diagnosis is a habit rather than a debate.
Author: Dr. Carl Lee Tolbert, PhD, CMRP, Wayward Leaders LLC, waywardleaders.com
Frequently Asked Questions
Why does my VFD keep losing communication with the PLC?
The most common cause is electrical noise coupled into the communication cable from routing it too close to motor power cables. Check the physical routing before suspecting the network hardware: separation from power wiring, shielded cable, and 90 degree crossings prevent most of these faults.
Can I use regular Ethernet cable to connect a VFD?
Not in a drive environment. Unshielded office-grade cable invites noise coupling from PWM switching, which shows up as CRC errors, retransmissions, and timeouts. Use shielded Cat5e or Cat6 at minimum, with industrial-rated cable for PROFINET installations.
Why do communication faults only happen in the afternoon?
A time-of-day or load-dependent pattern points to heat, not wiring. An overheated drive destabilizes its own communication interface, so the comm fault is really an overtemperature symptom, and the fix is cooling: clean the passages, verify the fans, and check the enclosure design.
Why did several drives drop off the network at once?
On a daisy-chained network, a single cable or port failure takes down every drive downstream of it. On serial trunks, missing termination causes reflections that degrade the whole segment as traffic grows. A ring topology like DLR survives a single failure by rerouting automatically.
Should VFDs use DHCP or static IP addresses?
Static. A DHCP-configured drive disappears from the network whenever the DHCP server is unreachable, which turns a server hiccup into a production stoppage. Assign static addresses, verify no duplicates exist, and document the register in the commissioning record.
Can the communication timeout setting itself cause faults?
Yes. If the drive's comm-loss timeout is set tighter than the worst-case gap between valid telegrams, normal network jitter and PLC scan variation will trip it with nothing actually wrong. Verify the configured value against the real telegram interval under full production load, and leave margin.
What should the drive do when communication is lost?
That is a commissioning decision, set by the loss-of-communication parameter: fault and stop, coast, hold last speed, or fall back to a preset. Choose it deliberately for each application, because the safe answer for a fan is not the safe answer for a conveyor feeding a machine.