PLC communication fault (network / remote I/O)
The PLC has lost communication with a device, remote I/O, HMI, or network — comms-fault indication, missing data, or remote I/O dropping out.
Safety first
Loss of comms to remote I/O can leave outputs in a defined or undefined state — confirm the configured behaviour. Make the area safe before testing. Follow site procedures.
Isolate, lock out / tag out, and prove dead before working unless a live test is specifically required, authorised, and carried out under proper supervision. Always follow local regulations, your site procedures, and the equipment manufacturer's documentation.
Apprentice mode
Full walk-through — the why, what readings mean, mistakes & safety.
Likely causes
Ranked from most to least likely.
- 1
Network cabling / connector fault
Most likelyA damaged or loose network cable, or a bad connector, breaks the link to the device or remote I/O.
- 2
Switch / network infrastructure fault
#2A failed network switch, port, or power to it drops the affected devices.
- 3
Configuration / address mismatch
#3Wrong IP/node address, duplicate addresses, or protocol settings stop communication.
- 4
Remote I/O / device powered down or faulted
#4The remote device has lost power or faulted, so it stops responding.
- 5
Comms port / card fault
Least likelyThe PLC's comms port or a device's comms card has failed.
Reports are saved on this device to reflect what you actually find.
Testing sequence
Work through one test at a time. Expected reading and what each result means.
On the tools? Job Mode shows one test at a time with thumb-sized buttons — your place and readings carry straight over.
Enter Job ModeIdentify exactly which device(s) dropped and check their and the PLC's comms LEDs.
A clear picture of which link is down.
Scope narrowed — check that link's cabling and the device power.
If many devices dropped, suspect shared infrastructure (switch/power).
View all expected readings at once
Fault-finding flowchart
The same logic as a decision tree.
- 1start
PLC comms fault
→ step 2 - 2decision
Did just one device drop, or many together?
Yes→ step 3No→ step 4 - 3decision
Is that link's cabling sound and the device powered?
Yes→ step 5No→ step 6 - 4result
Many dropped — suspect shared infrastructure (switch/power).
- 5decision
Do addressing/config and infrastructure check out?
Yes→ step 7No→ step 8 - 6result
Cabling or device-power fault — repair/restore.
- 7result
Suspect a comms port/card — replace per procedure.
- 8result
Address mismatch or infrastructure fault — correct/repair.
Common mistakes apprentices make
- Not checking the configured comms-loss behaviour of remote I/O.
- Overlooking shared infrastructure when many devices drop together.
- Duplicate or wrong addresses after a device swap.
- Assuming the PLC when a remote device simply lost power.
When to stop & escalate
Network architecture and infrastructure faults often involve IT/controls teams. Comms-card or port replacement follows site procedures with saved configuration.
If you're past your competence, authorisation, or the safe limits of the job — stop and hand it on. There's no fault worth getting hurt over.
Was this guide helpful?
Related faults
PLC I/O module faulted / showing module error
An I/O module shows a fault LED or the controller reports a module error — a whole block of inputs/outputs is dead or unreliable, not just one channel.
VSD communication / fieldbus fault
The drive has lost communication with the PLC/SCADA over its fieldbus (e.g. control by network) — comms-loss fault, no remote control, or the drive stops on comms timeout.
PLC output LED is on but the device doesn't work
The PLC output indicator says the output is energised, but the connected device (valve, contactor, lamp, motor starter) does nothing. The program thinks everything is fine.
Learn the theory
How the gear and circuits behind this fault actually work.