PLC Troubleshooting: Program Logic Faults

PLC Troubleshooting: Program Logic Faults

When a machine behaves unexpectedly, the fault may live in the hardware, the wiring, or the program itself. This lesson focuses on program logic faults — errors in the ladder logic that prevent a process from running as the control narrative intends. Finding these faults requires a systematic approach: online monitoring, cross-reference tools, and, when necessary, forced I/O.

Safety Before You Begin

Before connecting a laptop to a live PLC trainer, follow your facility's electrical safety rules. Even a low-voltage training panel can drive outputs that move actuators or energize loads. Apply lockout/tagout (LOTO) to any energy source before physically touching wiring or swapping modules. When working online in monitor mode, be aware that forcing an output ON can cause unexpected machine movement — warn anyone nearby, keep hands clear of all actuators, and only force tags in a controlled, supervised training environment. Never force I/O on live production equipment without a proper management-of-change process and a qualified observer. Wear the PPE required by your lab safety policy.

Going Online with a Running Program

"Going online" means your programming software connects to the PLC processor while the program is actively scanning. Most software (such as Studio 5000 for Allen-Bradley or CCW for Micro800 series) shows rung status highlighting: contacts that are logically true appear highlighted or bold; contacts that are false appear dim or unfilled. This live view lets you see exactly where logic flow stops.

To go online safely on a trainer:

1. Confirm the processor is in Run or Remote Run mode.

2. Connect via USB or Ethernet and select "Go Online" in the software.

3. Verify the software shows "Online" and the program revision matches — if the software warns of a mismatch, do not accept changes without instructor approval.

With rung highlighting active, run the process through its steps and watch which rungs fail to pass logic when you expect them to. A rung whose output coil never energizes despite inputs that look correct is your first clue.

Using the Cross-Reference Tool

A cross-reference (often Ctrl+R or a menu option) lists every rung that uses a specific tag — as an input contact, output coil, or operand of an instruction. This is critical because a bit used as a coil in one rung drives contacts scattered across dozens of other rungs. If a seal-in contact is missing or the wrong tag is used, the cross-reference reveals it immediately.

Practical steps:

1. Click on the suspect coil or contact tag.

2. Open cross-reference. The tool shows rung numbers, instruction type (XIC, XIO, OTE, etc.), and routine name.

3. Confirm the tag appears in every location the narrative requires. A missing entry is a missing rung element.

Forced I/O

The force table lets you override the physical state of an input or output bit in software. This is useful when a physical sensor is unavailable or when you want to isolate whether a fault is upstream (field wiring/sensor) or downstream (program logic).

• Force an input ON to simulate a sensor closing without touching the field device.
• Force an output OFF to prevent an actuator from moving while you study upstream logic.
• Forces must be enabled (a separate master enable bit) to take effect — enabling forces without understanding the consequences is dangerous.
• Always remove and disable forces when troubleshooting is complete. Leaving forces active can mask real faults and cause accidents.

The Three Common Seeded Fault Types

1. Wrong rung logic (incorrect contact type). A normally-open (XIC) contact used where the narrative requires a normally-closed (XIO), or vice versa, causes a rung to be true when it should be false or false when it should be true. Symptom: a step activates when it should not, or never activates. Correction: change the instruction type on the correct tag.

2. Incorrect timer preset. A timer (TON — Timer On-Delay) with the wrong preset value causes a delay that is too short or too long, making the process appear to stall or rush. Symptom: the next step triggers almost immediately or never triggers within a reasonable window. Correction: open the timer instruction, change the preset (PT) value to match the narrative specification, download, and verify the timing with a stopwatch.

3. Missing seal-in contact. A momentary pushbutton start signal must often be "sealed in" with a parallel XIC contact on the output coil's own bit, so the output stays ON after the button is released. Without it, the output pulses only while the button is held. Symptom: a step activates only while an input is held active, then drops out immediately. Correction: add the correct XIC contact in parallel with the start contact on that rung.

Writing the Fault Report

Your fault report is a professional document — the same format technicians use in industry maintenance logs. For each fault, record:

• Symptom observed: what the process did or did not do.
• Diagnostic steps taken: tools used (online monitor, cross-reference, force table), rungs examined, tags checked.
• Root cause: the specific program element that was wrong.
• Correction made: exact change (instruction type, tag, preset value, added contact).
• Verification method: how you confirmed the fix worked (online observation, test cycle, timing check).

Accurate, complete records protect you and your employer if a machine issue is questioned later.

Verification After Every Fix

After correcting a fault and downloading, always cycle the process from its initial state. Confirm each step transitions at the right time and for the right reason. If a second fault is still present, the symptoms may overlap — correct one fault at a time and re-test fully before moving on.