PLC Not Communicating?

Step 1: Make sure the PLC is actually online

A communication problem is not always a network problem. Start by verifying that the controller is alive and healthy before chasing switches, HMIs, or remote nodes.

• Check controller power and RUN or FAULT status.
• Look for major faults or network module faults.
• Verify the rack or processor has not lost power.
• Check module LEDs before touching software.

Step 2: Decide whether the problem is one path or the whole network

This is one of the most important decisions in communication troubleshooting. If only one HMI or one remote node is offline, suspect the path to that device. If multiple nodes drop together, suspect a bigger network or controller-level issue.

• Only the HMI is offline: suspect HMI IP, path, cable, switch port, or runtime issue.
• Only one remote I/O node is faulted: suspect that device, cable, port, or configuration.
• Multiple devices are down: suspect switch power, uplink failure, addressing conflict, or controller network issue.

Step 3: Check IP address, subnet, and duplicate IP conflicts

Wrong addressing is still one of the most common causes of PLC communication loss, especially after hardware replacement or rushed changes.

• Verify the PLC IP address matches the expected network.
• Check subnet mask and gateway where applicable.
• Confirm HMI and remote I/O nodes are on the right network.
• Watch for duplicate IP conflicts after adding or replacing devices.
• Do not assume the sticker on the device matches its current settings.

Step 4: Check cables, connectors, and switch ports

A surprising number of PLC communication faults come down to cable or switch problems, even when the system looks fine at first glance.

• Check link and activity LEDs on the controller, switch, HMI, and remote nodes.
• Swap patch cable or switch port if possible.
• Inspect M12 or RJ45 connectors for damage, loose seating, or broken locking tabs.
• Check whether a cabinet switch lost power.
• Look for damaged cables near motion, doors, or high-vibration areas.

Step 5: Verify HMI communication path

If only the HMI says communication lost, the PLC may still be fine. Narrow it down to the HMI side before assuming the controller is at fault.

• Check whether the HMI can still reach the PLC address.
• Verify the HMI is pointed to the correct PLC and path.
• Confirm the HMI runtime is running normally.
• Compare communication settings to a known-good backup if changes were made.

Step 6: Check remote I/O and Ethernet/IP nodes

If one node is faulted but the rest of the network is fine, treat it as a node-level problem first, not a whole-network failure.

• Check whether the node has power and status LEDs.
• Compare configured hardware to the real part number and revision.
• Verify the node IP address and subnet.
• Check for electronic keying or identity mismatch after replacement.
• Review controller diagnostics for module-specific fault text.

Step 7: Treat intermittent communication differently

If communication drops in and out, suspect unstable power, marginal switch ports, duplicate IP conflicts, vibration-sensitive connectors, or network hardware that fails under load.

• Trend whether dropouts happen during machine motion, load changes, or at random.
• Look for switch power instability or overloaded supplies.
• Inspect connectors and patch cables that may move or vibrate.
• Check whether another device coming online triggers the issue.

Step 8: Use the right next tool

Once you know whether the problem is controller health, network path, addressing, cabling, or node configuration, move into the right tool or support page instead of guessing.

Related PLC & Electrical Tools