PLC Fault Finding: A Technician's Quick Reference

Your filling machine stops mid-cycle. The operator hits the start button and nothing happens. The HMI screen shows "PLC Communication Fault." The maintenance tech arrives, stares at the panel, and says, "I am not a controls guy." So you call the integrator. They are available next Tuesday. That is five days of downtime on a machine that fills 200 bottles per minute.

This scenario plays out in plants every week. PLCs are the brains behind virtually every automated machine in your facility, and when they fault, production stops cold. But here is the thing: about 70% of PLC-related downtime is caused by problems that any trained maintenance technician can diagnose and fix. You do not need to be a programmer. You need to understand the hardware, know how to read fault indicators, and follow a logical troubleshooting sequence.

This guide covers PLC architecture from a maintenance perspective, the most common faults you will encounter, and how to find and fix them without calling an integrator every time a light turns red.

PLC Architecture: What You Need to Know

A PLC (Programmable Logic Controller) is an industrial computer designed to control machines and processes. Unlike your office computer, a PLC is built to operate in harsh environments: heat, vibration, dust, and electrical noise. It runs a single program in a continuous loop, reading inputs, executing logic, and writing outputs. That loop runs thousands of times per second.

Every PLC system has four main components. Understanding what each one does helps you narrow down where a fault is coming from.

Power Supply

The power supply converts your facility's AC power (typically 120V or 240V AC) into the 24V DC (or sometimes 5V DC) that the PLC modules need. It also provides field power for sensors and other 24V devices. When the power supply fails, everything goes dark.

Signs of power supply problems: PLC has no indicator lights at all, modules intermittently lose power (LEDs blink off and on), or the PLC faults under heavy I/O load (power supply cannot deliver enough current when many outputs are on simultaneously).

CPU (Central Processing Unit)

The CPU is the brain. It contains the processor that executes the program, the memory that stores the program and data, the communication ports, and usually a battery that maintains memory when power is off. The CPU reads all inputs, runs the program logic, and updates all outputs in a continuous loop called the scan cycle.

Signs of CPU problems: a solid or flashing fault LED on the CPU module, the PLC stops scanning (all outputs drop), or the scan time increases dramatically (program execution slows down).

Input Modules

Input modules are the PLC's eyes and ears. They read signals from field devices: proximity sensors, limit switches, photoeyes, push buttons, pressure transmitters, temperature sensors, and flow meters. Digital inputs read on/off states. Analog inputs read variable signals (typically 4-20 mA or 0-10V).

Signs of input module problems: the PLC does not see a sensor state change even though the sensor is working correctly, an analog input reads a fixed value that does not change when the process variable changes, or the channel LED does not match the physical state of the sensor.

Output Modules

Output modules are the PLC's hands. They send signals to field devices: solenoid valves, motor starters, variable frequency drives, indicator lights, and proportional valves. Digital outputs switch on/off. Analog outputs send a variable signal to control things like VFD speed or valve position.

Signs of output module problems: the PLC program shows an output as on, the module LED shows the channel as on, but the field device does not respond. Or the opposite: an output is off in the program but a field device is energized (a failed-on output, which is a safety hazard).

The Most Common PLC Faults

In our experience working with plants across multiple industries, PLC-related downtime breaks down roughly like this:

I/O wiring and field device failures: 45%. The PLC itself is fine. A sensor failed, a wire came loose, or a connector corroded. This is by far the most common category and the easiest to fix.
Communication failures: 20%. The PLC lost communication with the HMI, a remote I/O rack, or a networked device (VFD, robot, vision system). Usually a cable, connector, or network switch issue.
Power supply problems: 15%. Power supply degradation, voltage sags, or overloaded power supplies that cannot keep up with the I/O demand.
Program-related issues: 10%. Someone modified the program incorrectly, a recipe loaded wrong values, or a counter/timer reached an unexpected state.
CPU/module hardware failure: 10%. Actual hardware failure of a PLC module. This is relatively rare because PLCs are extremely reliable hardware.

Reading PLC Fault Indicators

Before you open a laptop or call anyone, look at the LEDs on the PLC modules. They tell you more than most people realize.

CPU module indicators (typical, check your specific PLC manual):

RUN (green, solid): Normal. The CPU is executing the program.
RUN (green, flashing): The CPU is in program mode or standby. It is not executing the program. Check if someone left it in program mode after a download.
FAULT (red, solid): A major fault has occurred. The CPU has stopped scanning. Check the fault log for the specific fault code.
FAULT (red, flashing): A recoverable fault. The CPU may still be running but something needs attention.
BATT (red): The backup battery is low. Replace it within the next scheduled maintenance window. If you lose power before replacing the battery, the program in RAM will be lost.
COMM (green, flashing): Normal communication activity on the port.
I/O (red): A fault has been detected on one or more I/O modules. The CPU is usually still running but the affected I/O point is not updating.

I/O module indicators:

Each channel typically has its own LED. A lit LED means that channel is on (energized for outputs, signal present for inputs).
Compare the LED states to what the program expects. If the program says an input should be on and the LED is off, the problem is in the field (sensor, wiring, or power to the sensor). If the LED is on but the program does not see it, the problem is in the module or backplane.
A module-level fault LED (usually red) means the module itself has detected an internal problem. Try cycling power to the module. If the fault persists, the module needs replacement.

Troubleshooting I/O Failures

Since field I/O problems account for nearly half of all PLC-related downtime, this deserves a detailed walkthrough.

Digital Input Not Working

Check the field device. Is the proximity sensor LED on? Is the limit switch physically actuated? Manually actuate the sensor and watch its indicator.
Check for voltage at the input terminal. With the sensor actuated, you should see approximately 24V DC between the input terminal and the common terminal. No voltage means the problem is the sensor, the wiring, or the sensor power supply, not the PLC.
Check the input LED on the module. If you have voltage at the terminal but the LED is off, the input channel may have failed. Try moving the wire to a spare input channel and updating the program address.
Check the program. If the LED is on, connect to the PLC and verify that the program sees the input as on. If the LED is on but the program shows the address as off, there may be an addressing error or a module configuration issue.

Digital Output Not Working

Check the program. Connect to the PLC and verify the output address is being commanded on. If not, the issue is in the program logic, not the hardware.
Check the output LED. If the program shows the output on and the LED is on, the PLC is doing its job. The problem is downstream: check the wiring to the field device, the field device itself (solenoid coil, contactor coil), and the power supply feeding the output circuit.
If the program shows on but LED is off: The output channel may have failed. This is common with relay-type output modules where the relay contacts eventually wear out. Solid-state outputs can also fail, typically failing off (open circuit).
Check the fuse. Many output modules have individual channel fuses or a group fuse. A blown fuse takes out one or more channels. Replace the fuse, but investigate why it blew. A shorted field device or wire will blow the new fuse immediately.

Analog I/O Problems

Analog signals (4-20 mA, 0-10V) are more sensitive than digital. Common analog I/O problems include:

Reading stuck at zero (or 0 mA): Open wire, failed transmitter, or no power to the transmitter. Check wiring continuity and transmitter power.
Reading stuck at maximum (20 mA or full scale): Shorted signal wire, or the process variable is actually at maximum. Disconnect the wire at the PLC input and see if the reading changes.
Erratic or noisy reading: Electrical noise pickup. Check that the signal wire is not routed alongside power cables. Use shielded cable with the shield grounded at one end only.
Reading below 4 mA: On a 4-20 mA loop, any reading below 4 mA means the loop is broken. The 4 mA "live zero" exists specifically so you can distinguish between "the transmitter is reading zero" (4 mA) and "the wire is broken" (0 mA).

Forced I/O Testing

Forcing is the ability to override the PLC's normal I/O state. You can force an input to appear on even when the physical sensor is off, or force an output on even when the program logic says it should be off. This is an extremely powerful diagnostic tool, and an extremely dangerous one if misused.

When to use forcing:

To test an output device when you cannot easily create the program conditions to turn it on. Example: you need to verify a solenoid valve works, but the machine needs to be in a specific state that is hard to reproduce.
To bypass a failed sensor temporarily while you wait for a replacement. Example: a safety interlock sensor failed in the open state, and you need to run production while the spare is being shipped.
To trace program logic by forcing inputs and watching which outputs respond.

Safety rules for forcing:

Never force an output on a machine where people could be in the danger zone. If you force a cylinder to extend and someone's hand is in the way, the safety interlocks that would normally prevent this have been bypassed.
Always document forces. Write down what you forced, why, and when. Remove all forces as soon as testing is complete.
Most PLCs have a "force" indicator LED or a status bit in the program that shows forces are active. Check this during every troubleshooting session. Someone else's forgotten force from last week could be causing your current problem.
Never leave forces in place as a permanent fix. If a sensor is bad, replace the sensor. If program logic is wrong, fix the program. Forces are a temporary diagnostic tool, not a band-aid.

Communication Faults

Modern PLC systems rely on Ethernet/IP, Profinet, Modbus TCP, or other network protocols to communicate with HMIs, VFDs, remote I/O racks, and other PLCs. When the network goes down, machines stop even though the PLC and all its local I/O are working perfectly.

Common communication fault causes:

Damaged Ethernet cables. Industrial Ethernet cables get stepped on, run over by forklifts, soaked in coolant, and chewed by rodents. A cable that tests fine with a continuity check can still fail under data communication because a single damaged conductor pair causes packet loss. Replace suspect cables with new, rated industrial Ethernet cables.
Bad connectors. M12 connectors that are not fully tightened allow moisture and dust ingress. RJ45 connectors in industrial environments should be avoided in favor of M12 or other sealed connector types.
Network switch failure. Unmanaged switches in control panels sometimes fail or lock up. Power cycling the switch often restores communication. If it happens repeatedly, replace the switch with an industrial-grade managed switch.
IP address conflicts. Two devices on the same network with the same IP address will cause intermittent communication faults that are extremely difficult to diagnose. Document your IP address assignments and keep the list updated.
Excessive network traffic. When a control network is shared with office traffic (cameras, printers, computers), network congestion can cause PLC communication timeouts. Control networks should be on isolated VLANs or physically separate switches.

Battery and Memory Faults

Most PLC CPUs have a lithium battery that maintains the program and data in RAM when power is removed. These batteries last 3-7 years depending on the manufacturer and how often the PLC loses power.

When the battery LED comes on, you have a window to replace it, but that window is only as long as the PLC stays powered. If you lose power with a dead battery, the program is gone. You will need to download it from a backup.

Battery replacement procedure (general):

Verify you have a current program backup before touching anything.
With the PLC powered on, remove the old battery and immediately install the new one. Most PLCs are designed for hot-swap battery replacement. The capacitor on the CPU board holds memory for 30 seconds to a few minutes.
Verify the battery LED turns off after replacement.
Document the replacement date on a label on the PLC panel door.

The bigger lesson: keep current program backups. Every PLC in your plant should have its program backed up on a server, and that backup should be updated after every program change. If you do not have a program backup process, one hard drive crash or one dead battery will cost you days of re-programming.

Program-Related Faults

Sometimes the PLC hardware is fine but the program is causing the problem. This is especially common after someone has made a program change, even a minor one.

Common program issues:

Timer values changed. Someone adjusted a timer for troubleshooting and forgot to change it back. Now a sequence times out before it can complete.
Forces left active. A technician forced an input during testing and forgot to remove the force. The sensor can now change state all day and the PLC will not see it.
Recipe or parameter errors. A recipe download sent wrong values to the PLC. Machine speeds, positions, or temperatures are outside normal range, causing the machine to fault on a safety limit.
Watchdog timeout. The program scan time exceeded the configured watchdog limit. This can happen if a program change added too much logic to a single scan, or if a communication instruction is timing out and holding up the scan.
Memory overflow. The program and data exceeded available memory. This is rare with modern PLCs but can happen on older processors when data logging or trending is added without checking available memory.

Building PLC Skills on Your Maintenance Team

You do not need every technician to be a PLC programmer. But every technician who responds to machine faults should be able to:

Read and interpret LED indicators on all four module types.
Check and replace fuses on I/O modules.
Verify voltage at input and output terminals with a multimeter.
Connect to the PLC with a laptop and go online to monitor the program.
Identify which rung of the program controls a specific output.
Check for active forces and remove them.
Read the fault log and clear faults after the cause is addressed.

These seven skills handle the majority of PLC-related calls. Formal PLC training classes are valuable, but the fastest way to build these skills is supervised hands-on troubleshooting. Pair a controls-savvy technician with one who is less comfortable around PLCs. The knowledge transfer happens naturally.

How Dovient Supports PLC Troubleshooting

The hardest part of PLC troubleshooting is not the technical work. It is finding the information you need: what does this fault code mean, which wire goes where, what was changed last time this machine had the same problem. When the knowledge base lives in a retired electrician's head or in a binder that disappeared three years ago, every PLC fault becomes a research project.

Dovient addresses this by making past repair data searchable and available at the machine. When a technician encounters a PLC fault, Dovient's troubleshooter can pull up every previous occurrence of that fault on that machine, along with what was found and what fixed it. If a similar fault occurred on a different machine in the plant, that shows up too.

Combined with structured root cause analysis on recurring PLC faults, this approach steadily reduces repeat failures and builds the team's collective troubleshooting capability. Every fix becomes a reference for the next one.

Want to see how this works for your control systems? Schedule a conversation with our team.