PLC Troubleshooting with Online Monitoring

Online monitoring is the single most powerful troubleshooting tool you have, and most engineers underuse it. Not because they do not know it exists, but because they do not have a systematic method. They go online, click around a few rungs, scratch their heads, and eventually start swapping hardware. That wastes time and sometimes creates new faults.

This post walks through a structured, step-by-step approach to PLC troubleshooting using live online monitoring in Studio 5000 / Logix, with notes for TIA Portal and CODESYS where the workflow differs. The same logic applies on any platform.

Why Online Monitoring Is Your First Move

A PLC in run mode with a programming terminal connected shows you exactly what the processor sees in real time: which contacts are open or closed, which coils are energised, what value is sitting in every tag. The scan cycle is typically 5 to 20 ms, so the display updates fast enough to catch most faults. You are not guessing based on indicator lights or HMI messages. You are reading the actual logic state.

The key discipline is: go online before you touch anything physical. A lot of faults are in the logic or in field wiring that shows up clearly in the tag browser. Pulling cards, swapping sensors or bumping setpoints first turns a 10-minute software diagnosis into a 2-hour hardware hunt.

PLC Troubleshooting Steps: The Online Workflow

Step 1: Connect and Check Controller Status

Open Studio 5000, go online to the controller. The first thing to read is the controller status banner at the top of the screen: RUN, FAULT, or REM PROG. If you see a fault, open the controller properties fault tab immediately. Every Logix controller stores the fault code, the fault type (minor vs major), and the exact routine and rung number where the fault occurred. A Type 4, Code 20 fault means a task watchdog overrun, for example. That alone tells you the fault is a timing or scan-time problem, not a field device problem.

Step 2: Find the Output That Is Not Doing What You Expect

Describe the symptom as precisely as possible: 'Conveyor 3 does not start when the start button is pressed.' That gives you an output tag to start from: Conv3_Run. In Studio 5000, press Ctrl+F to open the cross-reference and search for Conv3_Run. You will see every rung in every routine that reads or writes that tag.

Go to the rung that has Conv3_Run as an OTE or OTL coil. That is the output rung. Now look at the rung online. If the output coil is highlighted (true), but the physical output is not energised, the fault is in wiring or the I/O module, not in logic. If the coil is not highlighted (false), the logic is blocking it and you need to find why.

Step 3: Walk the Rung Backwards from the Coil

With the output rung open in online mode, look at each contact from right to left. Any contact that is not highlighted is an open condition blocking the rung. That contact is your next clue. It might be:

• An XIC (Examine If Closed) contact that should be true but is false: the tag or physical input is off when it should be on.
• An XIO (Examine If Open) contact that should be false but is true: something is active that should not be.
• A comparison instruction (GRT, LES, EQU) that is false because a value is out of range.
• A timer or counter done bit that has not set yet.

Note the tag name of the blocking contact. Cross-reference it. If it is a physical input tag like Conv3_StartPB, go to the I/O tree and check the module status. Is the bit reading 0 while the button is physically pressed? That is a wiring or sensor fault. If it is an internal bit like Conv3_InterlockOK, find where that bit is written and repeat the same backwards walk on that rung.

Step 4: Use the Tag Monitor and Watch Window

Once you have a suspicious tag, open a Watch Window (in Studio 5000, right-click the tag and choose 'Monitor Tag'). You can add multiple tags and watch their live values side by side. This is invaluable for analog values, counters and timer accumulators. If Conv3_SpeedRef is reading 0 when it should be 750, that explains why a speed-enable comparison is blocking the rung.

In TIA Portal, the equivalent is the Watch and Force Table (Watches tab). In CODESYS, it is the Watch List. All three let you log tag values over time if you add them to a trace or data log, which is useful for intermittent faults that do not stay present while you are looking.

Step 5: Check I/O Module Diagnostics

In the I/O tree in Studio 5000, every module has a status icon. A yellow triangle means a module fault or communication issue. Double-click the module and open its Module Properties. The Connection tab shows whether the connection to the backplane or remote adapter is healthy. The Fault tab shows the exact fault code. Common ones are:

Step 6: Use Forces Only as a Last Resort

Forcing a tag means overriding what the PLC logic writes to it and jamming it to a fixed value. It is useful for isolating whether a fault is in the logic or the field device, but it comes with real risk. If you force an output on, the machine moves. People can get hurt.

The legitimate use for forces is: force an input tag true to simulate a sensor that you cannot physically actuate safely, then watch whether the downstream logic responds correctly. If it does, the fault is in the sensor or its wiring, not the logic. If it does not, the fault is in the logic and you continue the rung walk.

A Real Troubleshooting Example

Here is a scenario I have seen more than once. A pick-and-place arm is not extending. The operator says the start button does nothing. Online monitoring reveals the Arm_Extend_Sol output coil is false. Walking the rung backwards:

1. XIC(Cycle_Active) is true. OK.
2. XIC(Part_In_Position) is true. OK.
3. XIO(Arm_Fault) is FALSE, meaning Arm_Fault is TRUE. That is the blocker.
4. Cross-reference Arm_Fault: it is set by a rung that checks XIC(Arm_RetractLS_OK) which is false.
5. The retract limit switch is not reading. Go to the I/O module: input channel 7 shows a channel fault (open circuit).
6. Check the wiring: the 24 V supply wire to the limit switch has a broken ferrule inside the terminal. Crimp it, and the fault clears.

Total time: 12 minutes from symptom to repair. Without online monitoring, you might have swapped the solenoid valve, checked the pneumatic supply, tested the output module, all before finding a broken wire at a terminal block.

Ladder Rung: Interlock Fault Detection with Online Monitoring Tags

The rung below shows the arm extend logic from the example above in a form you can actually build and test. It includes the retract limit switch interlock, a fault latch on the rising edge of Arm_Fault, and an HMI acknowledge path. Go online with this in Studio 5000 and you will see exactly which contact is blocking the extend output.

Cross-Reference: The Feature Most Engineers Forget

Cross-reference (Ctrl+F in Studio 5000, Ctrl+Shift+F in TIA Portal) shows every rung that reads or writes a tag. This is non-negotiable for programs with more than a few dozen rungs. When you find a suspicious tag, cross-reference it immediately. You want to see:

• Which routines write to the tag (these are the sources of the value).
• Which routines read the tag (these are places affected by the fault).
• Whether the tag is written in more than one place (a common source of unexpected overrides).
• Whether an OTL/OTU pair exists and whether the unlatch rung is ever reaching its coil.

One specific gotcha: a tag written by a Move or Copy instruction in a periodic task will override whatever the ladder sets in the main task. If a tag looks right in the ladder but keeps resetting, cross-reference it and look for non-ladder writes. This catches about one in ten 'the logic is wrong' complaints that are actually configuration issues.

When Online Monitoring Is Not Enough

Online monitoring shows the current state. Intermittent faults that clear before you go online need a different approach. The best tool here is a data log or trend on the suspicious tags. In Studio 5000, the Logix Designer Trend tool lets you sample up to about 50 tags at scan rate. Set it running, wait for the fault to recur, then examine the trace. You will usually see the exact moment the tag changed and which tag changed first.

For intermittent sensor dropouts specifically, the sensor dropout counter ladder technique covered in the Intermittent Sensor Faults post is a good companion to the online monitoring workflow here. Both approaches together give you a complete picture.

Quick Reference: Online Troubleshooting Workflow