PLC troubleshooting: a step by step method for finding faults

A machine has stopped and someone is asking you why. Or you're learning, and finding faults is a big part of the job. Either way, PLC troubleshooting comes down to a method. In the UK it's often called PLC fault finding.

This is a step by step method for any make of controller, with notes on Siemens and Allen-Bradley. It comes from the makers' manuals, which are linked at the bottom.

The PLC troubleshooting steps in short

1. Make it safe and get permission.
2. Get the operator's report, then go and look.
3. Work out whether it's hardware or logic.
4. Read the status lights and the fault buffer.
5. Watch the inputs and outputs online.
6. Follow the rung or line back from the output.
7. Fix it properly, test it and write it down.

Notice how late anything gets changed. Most of this is looking.

Step 1: Start with safety

A stopped machine isn't a safe machine. It may only be waiting on a signal, and when that signal appears it could start. So first find out what can move and what energy is still stored.

Isolation and lock out are for competent people following site rules, not something to pick up from a blog. In the US, OSHA's lockout/tagout standard, 29 CFR 1910.147, covers servicing and maintenance where a sudden start or stored energy could hurt someone, and it sets out a sequence for when power must go back on for a test. In the UK, HSE's overview of PUWER, the work equipment regulations, covers isolating equipment from all its power sources, including hydraulic and pneumatic.

Using a meter in a live panel, or plugging a laptop into a running controller, needs the right training and permission too.

Step 2: Get the operator's report

Ask the person who was there. What did they see? When did it start? Does it happen every time? What changed recently? A new sensor or last week's program edit can save you a lot of looking.

A good report does half the work. In the Stop doesn't stop it mission, Stop does nothing but switching off the Permit stops the pump. So the output can be turned off, and the problem is likely to be in how Stop is used. Then go and see it yourself if you can.

Step 3: Is it hardware or logic?

Follow the signal from the machine into the program and back out, and look for the first place it goes wrong.

Not every card has a light for every point, so check yours. A program doesn't wear out overnight, but sensors and cables do, so if nobody has edited the code, hardware is a sensible place to start.

Step 4: Read the status lights and the fault buffer

Is the controller even running? Has it recorded a fault? Write down what you find before anyone clears anything, because later faults can bury the one that started it.

On Siemens

Siemens calls its LEDs an initial tool for locating an error. On the S7-1500 CPU 1511-1 PN, green RUN/STOP with flashing red ERROR means a diagnostics event is pending, and yellow RUN/STOP on its own means STOP. The meanings are device specific, so look up your own CPU.

Then select the CPU in TIA Portal, open Online & Diagnostics and read the diagnostics buffer. It lists events in the order they happened, including module errors, program errors and changes to STOP.

On Allen-Bradley

On a Logix controller, a major fault means it has stopped running its logic. Open Controller Properties and the Major Faults tab shows a type and a code, which Rockwell's table explains. Minor faults don't shut the controller down and don't need clearing, but Rockwell says you should still monitor and correct them.

The Rockwell manual used here is a March 2004 edition, so your screens may differ. On MicroLogix, SLC 500 or other makers, the method holds but you'll need that manual.

Step 5: Watch the inputs and outputs online

Going online means connecting to the controller and watching values change as the program runs. First make sure your laptop's copy matches the controller. TIA Portal has an offline/online comparison for this.

In TIA Portal, program status shows values and logic results live, and a watch table lists the tags you pick. In Logix software you can use the Monitor Tags tab. Then operate the input the normal way, if that's safe and allowed, and see whether the tag follows.

Watch tables can write values as well as read them, so make sure you're only watching. Signals can also change faster than a screen can show. For faults that come and go, look at TIA Portal's trace or Logix trends.

Step 6: Follow the rung or line back

Start at the output that's wrong and read backwards. Which rung or line writes it? Which condition isn't what it should be? Go to that condition and ask again. You'll land on either an input, which sends you back to step 3, or logic that's wrong.

Check every place that writes that output. That's how you catch a double coil, where the same output is written twice. Here's one in Structured Text, where a Jog line was added later:

// Start and stop
IF Stop THEN
    Running := FALSE;
ELSIF Start THEN
    Running := TRUE;
END_IF;
PumpOn := Running;

// Jog, added for maintenance
PumpOn := Jog;

Each part looks fine on its own. But the program runs top to bottom on every scan, so the Jog line overwrites PumpOn and Start appears to do nothing. The fix is to write it once, as PumpOn := (Running OR Jog) AND NOT Stop;. In ladder, it's the same coil on two rungs. To practise spotting one, try the double coil challenge.

Rockwell's notes for RSLogix 5000 version 12 describe an option that warns when a bit used by an OTE, the ladder output instruction, is written elsewhere. Check how your version handles it.

Forcing I/O: the dangerous shortcut

Forcing overrides a value. A forced input reads what you set, whatever the real device is doing. A forced output does what you set, whatever the logic says. Rockwell lists fair uses, such as testing logic and checking output wiring, but says forces are only temporary, and its warning is blunt: "Forcing can cause unexpected machine motion that could injure personnel." Work out what the force will do first and keep people away from the machine. The same goes for removing one.

Here's what catches people out:

• Forces stay behind. The controller holds them, not your laptop, so they remain after you disconnect.
• Forces hide faults. A forced input can look healthy on screen while the real sensor is dead.
• Forces act straight away. If forcing is enabled, a new force takes effect immediately, and removing one can leave forcing enabled.

So check for forces at the very start, because someone may have left one behind. On a Logix controller with a FORCE light, solid means I/O forces are enabled, and flashing means a force value exists but forcing isn't enabled. On the Siemens CPU 1511-1 PN, an active force job is listed against a yellow MAINT LED.

Don't force anything on a real machine unless you're authorised and know exactly what will move, and never force past a stop or a guard to keep production going. Real safety functions need proper safety rated equipment and a competent person.

Step 7: Fix it through the proper route

Finding the cause doesn't give you the right to change the program. PLC software can often edit a running program, which Rockwell calls online edits, but changing live code on a running machine needs proper authority under your site's rules, the right people told, a backup and a way back.

Once a change is approved, test the case that failed, test that Stop still wins, and test a value mid range, not just the ends. Take off any forces or temporary links. Then write down what failed and what you changed.

Common causes worth checking first

• A double coil. The same output written in two places, as above.
• A stuck sensor. A sensor that's dirty, knocked out of line or jammed on looks just like bad logic. The same goes for a valve that never moved, which is why a command is not feedback.
• A chattering output. A reading wobbling around one limit starts and stops a pump repeatedly. The pump chatters shows why it needs hysteresis.

The one to take most seriously is a bypassed stop. It can be a path in the logic that gets round Stop, as in the Stop doesn't stop it mission, where Stop is TRUE when pressed:

// Faulty: the hold path never checks Stop
#PumpOn := (#Start AND NOT #Stop AND #Permit) OR (#PumpOn AND #Permit);

// Fixed: Stop and Permit now apply to both paths
#PumpOn := (#Start OR #PumpOn) AND NOT #Stop AND #Permit;

On a real machine, check how the button is wired first, because a normally closed button keeps its input on until someone presses it. A bypass can also be a wire link or a forced bit left from an old job. If you find a stop or guard bypassed, that's a safety matter, so tell the person responsible rather than quietly sorting it yourself.

Practise before it's real

A running line is a bad place to learn. PLC Gym runs in a web browser on its own simulator, with working 3D machines. The fault finding missions give you an operator's report and a broken program, and a failed test can be replayed scan by scan. Stop doesn't stop it is on Pro, which you can try free for 7 days. For harder problems, the expert challenges on Pro have competing faults and code that looks right until it isn't.

PLC Gym has limits. It isn't a real controller, it doesn't connect to real I/O, and it isn't made by or affiliated with Siemens or Rockwell. It won't teach you to use a meter, read a drawing or isolate a machine. There's no editor for RSLogix 500, MicroLogix, SLC 500, Omron or Mitsubishi, and its safety missions are for learning only. You'll still want the real software, such as TIA Portal or Studio 5000, and time beside an experienced engineer.

For the career side, read the PLC technician guide. If rungs are still new, start with ladder logic.

Sources

• 29 CFR 1910.147, The control of hazardous energy, OSHA
• PUWER overview, HSE
• S7-1500 Diagnostics function manual, Siemens, edition 11/2024
• Diagnostics Overview for SIMATIC S7-1200 and S7-1500, Siemens, 09/2018
• CPU 1511-1 PN manual, Siemens, edition 09/2016
• Logix5000 Controllers Common Procedures, publication 1756-PM001G, Rockwell Automation, March 2004
• RSLogix 5000 version 12.06 release notes, Rockwell Automation