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.
Full detail — causes, the why, and common mistakes.
Likely causes
Ranked from most to least likely.
Premium fault tree
The full ranked causes, test sequence and flowchart for this fault are part of Sparkie Sidekick Pro.
Coming soon — no payment required during preview.
Testing sequence
Work through one test at a time. Expected reading and what each result means.
Full test sequence
The step-by-step test flow with expected readings for this fault is part of Sparkie Sidekick Pro.
Coming soon — no payment required during preview.
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.
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.