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?
| Symptom | Likely Protocol | Where to Look First |
|---|---|---|
| The status LED shows solid red, RSLogix/Studio 5000 shows “Rack Fault.” | EtherNet/IP | IP address conflict, switch port, module keying |
| Modbus Poll or SCADA shows “Timeout” over Ethernet | Modbus TCP | Port 502 blocked, wrong unit ID, gateway config |
| RS-485 network with intermittent garbage data | Modbus RTU | Termination resistors, baud rate mismatch, wiring polarity |
| Siemens TIA Portal shows device grayed out, “no connection.” | PROFINET | Device name not assigned, VLAN/switch misconfigured |
| Bus fault LED (BF) solid or flashing red | PROFIBUS DP | Termination, address conflict, cable length/segment count |
| Node missing from scan list, MAC ID conflict | DeviceNet / CANopen | Bus power drop, terminating resistors, duplicate MAC ID |
| The broker shows client disconnected, no telemetry in the dashboard. | MQTT | Broker 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:
- Power and physical connection: Is the device actually powered, and is the cable seated and undamaged?
- Physical layer settings, termination, baud rate, polarity, or link speed/duplex for Ethernet-based protocols.
- Addressing, IP address, device name, station address, or MAC ID checked for conflicts.
- Logical configuration, module keying, GSD/EDS files, topology, or client IDs matching what’s actually deployed.
- 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.
