A PLC rarely fails completely without warning. Most downtime starts with a flickering indicator, an unexplained drop in I/O, or a communication fault that appears only under certain load conditions. The difference between a short interruption and a long shutdown is a structured troubleshooting method that isolates the cause rather than randomly replacing parts. This guide walks through the five most common PLC problems, the symptoms that point to each, how to diagnose them, and the fixes that restore reliable operation.
1. Power Supply Failure
The power supply is one of the most stressed components in a cabinet, because it handles constant voltage conversion, inrush currents, and ambient heat. A failing supply often causes the CPU to drop out, output modules to reset, or the controller to reboot intermittently.
- Symptoms: the power or CPU LED blinks or goes out; the PLC reboots under load; voltages drift; the 24 V DC bus sags when actuators energize.
- Diagnosis: measure the incoming AC and the DC output under load with a multimeter; compare readings against the nameplate; check for swollen capacitors, burned odor, or tripped fuses; isolate loads one at a time.
- Fix: replace the power supply if output voltage is out of spec; confirm the supply is sized for total load plus margin; add a separate supply for inductive loads if the bus is being pulled down.
2. I/O Module Faults
Input and output modules sit closest to the field, so they absorb surges, short circuits, and wiring faults. A single bad channel often looks like a sensor or valve problem until the module itself is tested.
- Symptoms: a channel stuck on or off; the module fault LED lit; burned terminals; inconsistent readings from analog modules; multiple channels failing together.
- Diagnosis: force the point in the programming software and verify at the terminal; measure field voltage and continuity; disconnect field wiring to separate a wiring fault from a module fault; inspect for shorted or grounded field devices.
- Fix: replace the faulty module after taking a backup; repair damaged field wiring; install proper fusing, surge suppression, and isolation so a field fault does not recur.
3. Communication Loss
As controllers connect to HMIs, drives, and upper-level systems over EtherNet/IP, Profinet, Modbus, or serial networks, communication faults become a leading cause of alarms. Losses may be intermittent and tied to noise, cabling, or network load.
- Symptoms: HMI shows offline or stale data; drives drop off the network; LEDs on comms modules flicker abnormally; timeouts in the event log; errors under heavy traffic.
- Diagnosis: check cable connectors, terminations, and switch LEDs; ping or scan network nodes; verify IP addresses, baud rates, and node addresses; isolate noise by testing with a known-good cable; examine grounding of communication lines.
- Fix: reseat or replace damaged cables; correct duplicate addresses or baud-rate mismatches; shield and ground fieldbus cabling away from power cables; add managed switches or repeaters where the network segment is overloaded.
4. Program Memory Loss or Corruption
A program that suddenly runs the wrong sequence, forgets settings, or will not start points to memory or battery problems. PLCs rely on a backup battery or non-volatile memory to retain the user program and retentive data while powered down.
- Symptoms: logic reverts to an old version; retentive registers reset; battery-low alarm; faults after a power cycle; the controller starts in an unexpected state.
- Diagnosis: check the battery status indicator and voltage; compare the online program against the last verified backup; review the event log for memory or CRC errors; confirm the program is stored in non-volatile memory and not only in RAM.
- Fix: replace the backup battery on schedule with power applied to avoid losing RAM; reload the verified program and back it up again; save the project to non-volatile storage; document firmware and program versions.
5. Grounding and Electrical Noise
Noise from VFDs, contactors, welders, and poorly routed cables can cause the most confusing faults: random trips, phantom inputs, and communication drops that vanish when you measure them. This is often misdiagnosed as a failed module when the real cause is the installation.
- Symptoms: inputs trigger without a connected device; outputs chatter; analog readings drift or jump; communication errors correlate with motor starts; faults disappear during quiet periods.
- Diagnosis: use an oscilloscope or power-quality meter on the DC bus and analog signals; observe whether faults coincide with equipment switching; check single-point grounding, shield continuity, and separation of signal and power cabling; verify absence of ground loops.
- Fix: route low-voltage and signal cables away from motor and power lines; ground shields at a single point; install surge suppression and snubbers on inductive loads; add line filters and isolate noisy drives; bond cabinet panels to a clean earth ground.
Quick Troubleshooting Reference
| Problem | First symptom to check | Diagnostic step | Typical fix |
|---|---|---|---|
| Power supply failure | CPU LED off or rebooting | Measure DC output under load | Replace supply; right-size the load |
| I/O module fault | Channel stuck or module LED lit | Force the point and test at the terminal | Replace module; add fusing/suppression |
| Communication loss | HMI offline or stale data | Check cables, addresses, and terminations | Repair cabling; fix addresses; shield lines |
| Program corruption | Logic reverts after power cycle | Check battery and compare to backup | Replace battery; reload verified program |
| Grounding and noise | Phantom inputs or drifting analogs | Observe faults against motor starts | Reroute cables; single-point ground; add filters |
A Practical Diagnostic Routine
Whenever a fault appears, work from the outside in: confirm power, then wiring and field devices, then the I/O module, then the program, and finally the network. Always take a program backup before replacing a module, and document what you changed so the root cause is not repeated. If a replacement module or power supply is difficult to source because the platform is mature, our Discontinued Products range may help, or you can send us the part number for assistance.
Frequently Asked Questions
Why does my PLC reboot only when a motor starts?
That pattern usually points to a power supply that is undersized or failing, or to noise coupling into the DC bus. Measure the supply under load and check whether the inrush voltage dip triggers the controller's low-voltage reset.
How can I tell a sensor fault from an I/O module fault?
Disconnect the field wiring and force the point from the programming software. If the channel responds correctly with wiring removed, the problem is in the field device or wiring; if it still fails, the module is likely at fault.
What causes random phantom inputs?
Phantom inputs are most often caused by electrical noise, poor shielding, floating inputs, or ground loops. Route signal cables away from power lines and confirm that unused inputs are tied to a valid state.
How often should I replace the PLC backup battery?
Follow the manufacturer's recommended interval, commonly every one to five years depending on the battery type, and replace it with power applied so RAM contents are not lost. Treat any battery-low alarm as urgent.
SHLY-PLC is an independent distributor of industrial automation parts. All brand names, model numbers, and trademarks are the property of their respective holders and are used only for identification and compatibility reference.