Troubleshoot with live values and forces

The Core Idea

Live values show what the controller is reading and commanding while a program runs. Troubleshooting uses that evidence to locate the failed condition; a force deliberately substitutes a value to test a specific explanation.

What you will learn

• Trace a machine that will not start from its output rung back to the contact that blocks it, using live values.

• Tell a field fault from a logic fault by comparing each input bit with its real device, and the output bit with the real actuator.

• Use a force to prove a suspect device, and remove every force when you are done.

Why it matters

Changing logic before locating the problem can hide its cause. A deliberate observation and test gives you evidence for the next action.

The problem

"Conveyor 2 will not start." Conveyor 2 feeds a downstream conveyor, and it must never run onto a stopped one.

The program is one rung: START_PB in parallel with a MOTOR_RUN seal-in, then normally open contacts on STOP_PB, OL_OK, and DOWNSTREAM_RUN in series, driving MOTOR_RUN. It is the start/stop pattern from Interlocks and Permissives: each condition after the seal-in blocks a start and also stops a running conveyor. This Stop is an ordinary operating stop. Emergency stops belong to a separate safety system, such as a safety relay or a safety-rated controller, not to ordinary programmable logic controller (PLC) logic; they are not part of this program, and nobody forces or bypasses them.

When a machine will not start, the cause is one of three things:

• A field fault: something outside the program has failed. A device, its wiring, a fuse, an input or output card, or a contactor. The program may be right, but a wrong value reaches its input, or its output never reaches the machine.

• A logic fault: the program is wrong. The right signals reach the PLC, but the rung does the wrong thing with them: a wrong contact type, a wrong tag, a missing or extra condition.

• No fault at all: a permissive or interlock is doing its job. The downstream conveyor really is stopped.

Work from the output back:

1. Start at the output. Is the output bit ON? If it is ON and the machine does not run, the fault is on the output side, in the field. If it is OFF, go on.

2. Follow the output's rung and find the contacts that are open, using the live values and the power flow.

3. For each open contact, compare its tag's live value with the real device. A bit that disagrees with its device points at the field. A bit that agrees with its device, under a contact that is open anyway, points at the program.

4. Prove it with a force, then remove the force.

Predict

In this simulator, the human-machine interface (HMI) buttons stand in for the field devices; the ladder and the scan stepper show what the PLC sees. Hold START for a moment to run the conveyor. Then, in the Fault injection panel under the demo, choose Broken wire, tag DOWNSTREAM_RUN, and press Inject fault. Compare the DOWNSTREAM RUNNING button with the DOWNSTREAM_RUN contact and its value in the scan stepper.

Try it

Keep using the demo above. It appears once you lock in a prediction. Hold each button for a moment; the program reads inputs once every 100 ms scan.

1. Input-side field fault. With the broken wire still injected, hold START. Nothing happens. Gather the evidence: MOTOR_RUN is OFF; the open contact in its rung is DOWNSTREAM_RUN; its live value is FALSE; the DOWNSTREAM RUNNING button, the real device, is lit. The bit disagrees with the device, so the fault is in the field. Press Clear fault and hold START: the conveyor runs again.

2. Output-side field fault. With the conveyor running, choose Failed output, tag MOTOR_RUN, and inject it. The rung stays true, and MOTOR_RUN stays TRUE in the ladder and the scan stepper, but CONVEYOR shows the motor stopped. The fault list says what happened: the PLC commands TRUE, the field device is FALSE. The program did its part, so the fault is in the output card, a fuse, the wiring, or the contactor. Clear the fault.

3. No fault at all. Click DOWNSTREAM RUNNING to turn it off, as if the downstream conveyor stopped. Conveyor 2 stops. Its contact is open and its input reads FALSE, and this time the device is off too. Everything agrees: the interlock is doing its job. Turn it back on and hold START.

While a fault is injected, the HMI buttons keep showing the device, while the PLC reads the faulted value. That difference is exactly what you look for on a real machine.

Look closer

Live values tell you which of these you have. A force tests that conclusion. A force tells the PLC to use a value you choose instead of the real one: for an input, instead of what the input card reads; for an output, instead of what the program writes.

• Force a suspect input to the state its device is really in. If the machine now behaves, the program is fine, and the fault is in the field. If it still does not, look at the program.

• Force an output on a real controller to prove the output circuit: if the contactor pulls in, the card, wiring, and contactor work. This lesson's editor forces inputs only.

Forces are dangerous. A forced input makes the program ignore the real device, so it can start a machine or remove a protection the program relies on. A forced output runs equipment whatever the program says. Force only with permission, with the machine and the people near it in a safe state, and never force or bypass a safety function. Remove every force when you finish; controllers show an indicator while any force is active.

In the editor embed below, setting an input in the tag list forces it: the tag is highlighted in blue and gets a Clear button, which removes the force and returns the input to what the field reports. The Fault injection panel acts between the device and the input card, and in this simulator it takes priority over a force on the same tag. On a real controller, a force on an input replaces whatever the card reads. The exercise below needs no injected fault.

Change it

Conveyor 3 is built the same way, and it will not start either. Its program was edited last week. Out on the machine, Stop is released, the overload relay is healthy, and the downstream conveyor is running: you can see it moving. The editor's tag list shows what the PLC reads: STOP_PB TRUE, OL_OK TRUE, and DOWNSTREAM_RUN FALSE.

1. Press Start: in the tag list, set START_PB TRUE, then FALSE. The conveyor does not start.

2. Follow the MOTOR_RUN rung. Two contacts are open.

3. DOWNSTREAM_RUN reads FALSE, but the downstream conveyor is running. The bit disagrees with its device, so suspect the field. Prove the program side: set DOWNSTREAM_RUN TRUE in the tag list, which forces it. Its contact closes, but the rung is still blocked.

4. OL_OK reads TRUE, and the relay is healthy. The bit agrees with its device, yet its contact is open. That is a logic fault. Repair it.

5. Press Start again. The conveyor runs. With the downstream input forced, you have proved that the rest of the program works.

6. Press Clear beside DOWNSTREAM_RUN. The force is removed, the input reads FALSE again, and the conveyor stops. The field fault is still there, and it is a job for the electrician: the auxiliary contact on the downstream starter and its wire to the input.

7. Press Validate. The checks run your repaired program with healthy field signals.

Show the repair

The OL_OK contact is normally closed. OL_OK is TRUE while the relay is healthy, so a normally closed contact is open exactly when the conveyor may run, and closed only when the overload has tripped. Change it to a normally open contact. Leave the DOWNSTREAM_RUN contact alone: the program is right about that signal, and the field is wrong. Removing that contact would make the conveyor start, and then run onto a stopped downstream conveyor.

Check yourself

Many motor starters have an auxiliary contact wired back to the PLC as run feedback. Comparing the command with the feedback lets the program report output-side field faults by itself, without anyone watching the machine.

The challenge editor opens with the tags MOTOR_CMD (the motor command), MOTOR_FB (the contactor's run feedback), FB_TIMER, and FB_FAULT, and no rungs. Build FB_FAULT:

• It turns on once MOTOR_CMD and MOTOR_FB have disagreed for 500 ms without a break, in either direction: commanded on with no feedback (the contactor failed to pull in), or feedback with the command off (it failed to drop out).

• It turns off as soon as they agree again.

• A motor that is off on purpose, with no feedback, is not a fault.

In the editor's tag list, set MOTOR_CMD and MOTOR_FB TRUE or FALSE to try each case. A real contactor takes some time to pull in and drop out; the checks allow it 200 ms. They also include a contactor that never pulls in, one that never drops out, late feedback, and two short dropouts. Run them as often as you need.

Hint 1

In which two situations do the command and the feedback disagree? And why must the fault wait before turning on?

Hint 2

Put the two disagreements in parallel and let them enable an on-delay timer (TON), so a normal pull-in or drop-out does not raise the fault. Use the timer's Done bit for FB_FAULT.

Hint 3

Path 1: a normally open MOTOR_CMD contact and a normally closed MOTOR_FB contact. Path 2: a normally closed MOTOR_CMD contact and a normally open MOTOR_FB contact. Both paths enable FB_TIMER with a 500 ms preset.

Show the worked solution

1. Two parallel paths, MOTOR_CMD with a normally closed MOTOR_FB contact, and a normally closed MOTOR_CMD contact with MOTOR_FB, enable the on-delay timer FB_TIMER, preset 500 ms.

2. A normally open FB_TIMER.Done contact drives the output coil FB_FAULT.

The timer runs only while the two signals disagree, and an on-delay timer starts again from 0 whenever its enable drops. A normal 200 ms pull-in, or two short dropouts, never reach 500 ms. When the feedback finally agrees, the timer resets and the fault clears. A stopped motor with no feedback is an agreement, so it never enables the timer.

What happened and why

The program can act only on what reaches its inputs, and the machine can do only what reaches its outputs. Live values show both sides at once. Starting at the output tells you which side to look at. An open contact tells you which signal blocks the rung. Comparing that signal's bit with the real device tells you whether the fault is in the field or in the program. A force then tests the conclusion: it gives the program the value the device should be sending, so if the machine responds, you know the program and everything downstream of it are fine.

That is also why a field fault is not fixed in the program. DOWNSTREAM_RUN protects the downstream conveyor from being buried. Deleting its contact, or leaving a force on it, would get conveyor 2 running and quietly remove that protection. A logic fault is the opposite: the field is fine, and the program has to change.

Run feedback, from the challenge, turns the output-side check into part of the program. Plants use the same idea for valves with limit switches, for pumps with flow switches, and for anything else whose command and response can be compared.

Common mistakes

• Changing the program to get around a field fault. Cause: deleting or bypassing the contact whose input is wrong. Symptom: the machine starts, but the interlock no longer protects anything; here, conveyor 2 runs onto a stopped conveyor. Fix: repair the device or wiring, and keep the program as it is.

• Fixing a logic fault by deleting the contact. Cause: removing the open OL_OK contact instead of correcting its type. Symptom: the conveyor starts, and it also starts and keeps running with the overload relay tripped. Fix: change the contact to the type that matches the signal: normally open for a signal that is TRUE when healthy.

• Leaving a force in place. Symptom: the machine runs with a device the program can no longer see, and the next person to troubleshoot it is misled. Fix: remove every force when you finish, and check the controller's force indicator.

• Replacing parts before reading the live values. Symptom: a new sensor fixes nothing, because the fault was in the program, or the program is edited when a wire was broken. Fix: compare the input bit with the device first; it tells you which side to work on.

• A feedback check with no delay. Symptom: every normal start and stop raises the fault, because a contactor needs time to pull in and drop out. Fix: let the disagreement run an on-delay timer.

Platform notes

The editor's palette labels the contacts NO (normally open) and NC (normally closed), and the timers by their IEC names.

The normally open and normally closed contacts are the XIC (Examine If Closed) and XIO (Examine If Open) instructions, and the output coil is OTE (Output Energize). Forces are installed in the programming software and then enabled for the controller; the controller's FORCE indicator lights while forces are active.

Forces are set in a force table in TIA (Totally Integrated Automation) Portal and apply to input/output (I/O) addresses. The central processing unit (CPU) shows when a force is active; on many models the MAINT indicator lights. A watch table can also modify a value once, which the program can overwrite on its next scan; a force stays until you remove it.

Enable JavaScript to run the embedded simulator and complete the interactive exercises.