PLC Troubleshooting: Finding and Fixing Problems in Minutes

LED Indicators: Your First Information Source

When a machine stops unexpectedly, the first thing every technician should check is the LED indicators on the PLC and its I/O modules. These LEDs provide immediate diagnostic information without any software tools.

CPU Status LEDs

I/O Module LEDs

Each input and output module has individual channel LEDs. An input LED that is ON means the field device is sending a signal (sensor active). An output LED that is ON means the PLC program is commanding that output ON.

Quick Diagnostic Technique

If a motor will not start, follow this sequence: check the output LED for the motor contactor. If the LED is ON but the motor does not run, the problem is downstream (contactor, wiring, overload, mechanical). If the LED is OFF, check input LEDs for the start button and all safety interlocks. If the start button input LED activates when pressed but the output stays OFF, the problem is in the program logic. This hardware-level check takes 30 seconds and immediately narrows the search area.

Watch Tables

A watch table (also called a variable table or tag monitor) displays real-time values of PLC variables while the program runs. It is the most commonly used online debugging tool.

In TIA Portal, CODESYS, or Studio 5000, you create a watch table by adding variables:

| Variable Name      | Type  | Value | Comment               |
|--------------------|-------|-------|-----------------------|
| bStartButton       | BOOL  | FALSE | Start pushbutton I0.0 |
| bStopButton        | BOOL  | TRUE  | Stop button I0.1 (NC) |
| bMotorContactor    | BOOL  | FALSE | Motor output Q0.0     |
| bMotorRunning      | BOOL  | FALSE | Motor feedback I0.4   |
| nMachineState      | INT   | 0     | Current state number  |
| rTemperature       | REAL  | 23.7  | Tank temperature      |
| ctuPartCount.CV    | INT   | 847   | Parts produced today  |

Best practices: create separate tables for different machine sections (filling, conveyor, packaging). Include both inputs and outputs to see cause and effect together. Add the state variable to know which sequence step is active. Include timer elapsed times to verify timing behavior. Save watch tables as part of the project for future troubleshooting sessions.

Watch tables also allow overriding values for testing:

• Modify: changes a value for one scan cycle only, returns to program-calculated value on the next scan
• Force: overrides a value persistently, ignoring the program, until the force is explicitly removed

Always remove all forces after testing. A forgotten forced output can cause unexpected machine behavior weeks later. Most PLCs display a warning icon when forces are active. Some plants require a "force log" where every force is documented with a reason and expected removal time.

Forcing is powerful for testing outputs without the correct input conditions being met, but it bypasses the program logic entirely. If you force an output ON, no stop button or safety interlock in the program can turn it OFF. Use forces with extreme caution on running machinery.

Online Monitoring

Online monitoring displays the program logic with live values overlaid. In Ladder Logic, green highlighting shows power flow through contacts, making it immediately obvious why an output is ON or OFF. You can trace the logic path and find exactly which contact blocks the circuit.

In Structured Text online mode, variable values appear next to their names:

IF rTemperature {23.7} > 85.0 THEN        // FALSE - not executed
    bOverheatAlarm {FALSE} := TRUE;
ELSIF rTemperature {23.7} < 20.0 THEN      // FALSE - not executed
    bUndertempAlarm {FALSE} := TRUE;
ELSE                                        // TRUE - this branch runs
    bOverheatAlarm {FALSE} := FALSE;
    bUndertempAlarm {FALSE} := FALSE;
END_IF;

The curly-brace values show the live state. You can see which branch of the IF statement is executing and why.

Some PLC environments support breakpoints in Structured Text, allowing you to pause execution at a specific line. Use this carefully because pausing the scan cycle stops all outputs. Breakpoints are safe during commissioning but should never be used on running production machines.

Tracing and Recording: Data Logger

When a problem occurs intermittently or too fast to observe in real-time, a trace (data recorder) captures variable values over time and displays them as a timeline graph.

Setting up a trace involves: selecting variables to record (inputs, outputs, state variables, analog values), setting the recording duration (10 seconds to 5 minutes), setting the sample rate (1ms for fast events, 100ms for slow processes), and defining a trigger condition.

Useful trigger conditions include: rising edge (start when a fault activates), falling edge (start when a motor stops), value threshold (start when temperature exceeds a limit), and pre-trigger buffer (capture data from before the event, often the most valuable information).

Example: a packaging machine stops randomly once or twice per shift. Configure a trace on bConveyorRun, bBottleSensor, bSealerReady, bFaultActive, and nMachineState. Set 10ms sample rate, trigger on falling edge of bConveyorRun, with 5 seconds of pre-trigger. When the stop occurs, the trace reveals that bSealerReady drops FALSE 200ms before the conveyor stops. This was invisible to the operator but the trace captured it clearly, directing the investigation to the sealer subsystem.

A Systematic Troubleshooting Methodology: 5 Steps

Experienced technicians follow a structured approach rather than randomly checking connections.

Step 1 - Observe and Gather Information: What is the machine supposed to be doing? What is it actually doing? When did the problem start? What changed? Is it constant or intermittent? Are there HMI alarm messages?

Step 2 - Check the Electrical Layer: Verify power supply voltages (24V DC, 120V AC, 480V AC). Check PLC status LEDs (RUN/STOP/ERROR). Inspect I/O module LEDs. Look for tripped breakers, blown fuses, and tripped overload relays.

Step 3 - Check the Software Layer: Go online with the PLC. Open a watch table and monitor relevant inputs (does the PLC see correct sensor states?), outputs (is the program commanding correctly?), and the state variable (which step is the program stuck on?).

Step 4 - Isolate the Cause: The problem falls into one of three categories: input problem (sensor not activating, broken wire, faulty module), logic problem (program bug or unexpected condition), or output problem (PLC commands correctly but field device does not respond).

Step 5 - Fix and Verify: Apply the fix (replace sensor, repair wiring, correct logic). Test under normal operating conditions. Document what was found and changed. Monitor for recurrence over the next production shift.

Practical Example: Diagnosing a Stopped Production Line

A bottle filling line has stopped. The HMI shows no specific alarm. The operator says it ran fine five minutes ago.

Step 1 - Observe: Conveyor stopped, bottles queued at infeed, fill valves closed. No visible mechanical damage.

Step 2 - Electrical: PLC in RUN mode (green LED). Power supply 24.1V (normal). Start button input activates when pressed. Safety circuit LEDs show all guards closed. Motor output LED is OFF.

Step 3 - Software: Open the watch table.

nMachineState    = 3 (WAITING_FOR_BOTTLE)
bBottleInPosition = FALSE
bConveyorRun     = FALSE
bInfeedSensor    = TRUE (bottles queued)
bPositionSensor  = FALSE (no bottle at fill)

The machine is waiting for a bottle at the fill position, but the position sensor reads FALSE even though bottles are clearly present upstream.

Step 4 - Isolate: The position sensor input LED on the PLC module is OFF. Check the physical sensor: its LED is also OFF, even with a bottle directly in front of it. The proximity sensor has failed.

Step 5 - Fix: Replace the proximity sensor. Verify the input LED activates with a bottle present. The machine resumes filling. Document the replacement with date and part number. Total troubleshooting time: approximately 8 minutes from observation to resolution.

Summary

PLC troubleshooting uses a layered approach: LED indicators for immediate hardware status, watch tables for real-time variable monitoring, online monitoring for visual logic tracing, and data recording for capturing intermittent faults. The five-step methodology (observe, check electrical, check software, isolate, fix and verify) provides a systematic framework that prevents wasted time on random guessing. The bottle filling line example demonstrates how this methodology quickly narrows a problem from a vague symptom to a specific faulty sensor in under 10 minutes.