PLC Fundamentals & I/O Diagnosis
Scan cycle, forcing, and proving whether the fault is field-side or logic-side.
- The scan cycle and what it explains
- Field side versus logic side
- Device, module LED and bit
- Walking an output chain
- Forcing, and its discipline
What it is
A PLC does one thing in a loop, forever: read the inputs, solve the logic, write the outputs. Everything else is detail.
It is also one of the most reliable devices on the plant. Processors and I/O cards do fail, and they fail far less often than the wiring, the field devices and the mechanical condition of everything attached to them. That is worth saying at the start, because "it must be the PLC" is where a lot of afternoons go.
The question this chapter answers
Chapter 8 got you to a false input bit and stopped. This chapter is the next step: is the field device actually doing what the input claims, or not?
That is the field-side / logic-side split, and it decides which tool you pick up. Field-side faults are found with a meter while standing at the machine. Logic-side faults need software. Working out which side you are on takes about a minute and is usually the difference between ten minutes and an afternoon.
The scan cycle, and the three things it explains
Read inputs into an image table → solve every rung → write the output image to the modules → housekeeping → repeat. Typically 1 to 20 ms per pass.
Three practical consequences fall out of that:
- Inputs are a snapshot. A pulse shorter than one scan can be missed entirely. If a fast event is being lost, that is a scan problem, not a sensor problem, and the fix is a high-speed input or a latch rather than a new sensor.
- Outputs change at the end of the scan, not the instant a rung solves. So a bit set in rung 5 and cleared in rung 90 leaves the module seeing only the final state — Chapter 8's last-write-wins, seen from the hardware.
- Rung order matters, for the same reason.
How it works
The chain, and where you can get at it
The chain has a small number of links and every one has an observable state, so the method is simply to walk it until the story changes. The fault is between the last link that is right and the first that is wrong.
That sounds obvious written down and it is routinely skipped, because the temptation is to jump to the most sophisticated observation available — the program — rather than the cheapest one.
Three lights, and what their disagreement means
The module LED is the most under-used diagnostic on any plant. It sits between the wiring and the software and tells you, for free, which side of the divider you are on:
- Device operating, LED dark — the module never saw it. The fault is the wiring, a terminal, or the common. Measure at point 2.
- LED lit, bit false in the program — the module saw it and the program did not. That is a module fault or an addressing problem, and it is the only one of these that genuinely points at the PLC.
- LED lit, bit true, machine still not working — the input path is perfect. Go back to Chapter 8 and read the rung.
Outputs are the same chain in reverse
For an output that will not operate, walk it the other way:
- Does the program command the bit? If not, it is a logic fault.
- Does the module's LED light? If the bit is on and the LED is dark, the module channel has failed.
- Is there voltage at the output terminal? LED lit with no voltage at the terminal is a failed output device — a welded or open relay contact, a dead triac, a blown fuse on the group.
- Is there voltage at the actuator? Voltage at the terminal but not at the coil is the wiring between them.
Output module types
Worth knowing because they fail differently:
- Relay — dry contacts, will switch AC or DC, slowest, and they wear out. Welded contacts are a real failure and produce an output that will not turn off, which is Chapter 3's dangerous parallel-fault character.
- Transistor — DC only, polarity matters, fast, no moving parts. Sourcing and sinking versions, exactly as in Chapter 7.
- Triac — AC only, no moving parts, and notable for a small leakage current when off that can hold a sensitive load partially energized.
Forcing, properly
A force overrides the image table: forcing an input makes the logic read your value instead of the module's, and forcing an output makes the module drive your value regardless of what the logic decided.
It is a genuinely powerful diagnostic. It is also a live change to a machine, and it is invisible — nothing on the machine looks different.
The discipline is short and non-negotiable: know why you are forcing before you do it, tell the people affected, record it, and remove it before you leave. Never use a force to prove a machine works, and never leave one in as a repair.
Commons, grounding and noise
Most discrete I/O is grouped, and each group shares a common return. A broken or loose common takes out every point in that group at once and looks convincingly like a failed module.
Noise is the other shared-path problem. Analogue signals and encoder feedback run alongside drive output cables at some point in nearly every machine, and the fast switching edges from Chapter 6 couple into them. Screened cable grounded at one end only, and separation from drive cables, are the usual remedies — and an analogue value that gets noisier when a drive runs is diagnostic on its own.
What normally fails
- Symptom
- A field device plainly operates but its input LED never lights
- Likely cause
- Wiring, a terminal, or the group common
- How common
- Very common
The device works, the module never saw it, so the fault is between them. Measure at the input terminal: voltage present there with a dark LED is a module channel; no voltage is the wiring or a termination. Check the common before condemning anything.
- Symptom
- Several outputs in the same group stop working at once
- Likely cause
- A blown group fuse, a lost common, or a supply to that section
- How common
- Common
The shared thing is the fault. This is the highest-value pattern in the chapter, because it converts a list of symptoms into one cause and it is visible from the symptom list alone before any measurement.
- Symptom
- An output will not turn off, or a machine will not stop
- Likely cause
- A welded relay output contact, or a forced bit
- How common
- Common
Both produce an output that ignores the logic. Check the force table first because it costs nothing; a welded contact then shows as an output terminal that stays live with the module LED dark. This is a dangerous failure — the parallel-fault character from Chapter 3 — and it is worth treating as urgent.
- Symptom
- A machine that was fine after a card replacement behaves strangely
- Likely cause
- Addressing changed, or the replacement is a different type from the original
- How common
- Occasional
Sinking versus sourcing, relay versus transistor, or a slot's addressing not matching the program. The tell is that the fault appeared with the work rather than with the machine, which is a general principle worth more than the specific case.
- Symptom
- A fast event is intermittently missed — a small part, a quick pulse
- Likely cause
- The event is shorter than the scan, so some scans never see it
- How common
- Occasional
Not a sensor fault and not repairable by replacing the sensor. The remedies are a high-speed input, a hardware latch, or slowing the event down. The clue is that the misses are random rather than correlated with anything physical.
- Symptom
- An analogue reading is unstable, and gets worse when a drive runs
- Likely cause
- Noise coupled into signal cabling from drive output cables
- How common
- Occasional
Screening grounded at one end, separation from drive cables, and checking that the screen has not been left disconnected at a junction box. The correlation with the drive running is the diagnosis — it is rarely available so cleanly.
- Symptom
- The whole machine is dead and everything looks healthy
- Likely cause
- The processor is in PROG rather than RUN, or has faulted
- How common
- Occasional
Embarrassing to miss and free to check. Look at the mode switch and the processor status LEDs before anything else, and read the fault log if it has faulted — it will usually say why.
How to troubleshoot it
Look at the processor first — mode and status LEDs
RUN or PROG, and any fault indication. Thirty seconds, no tools, and it occasionally ends the job. If the processor has faulted, read the fault log before clearing it: clearing first destroys the only evidence of why.
Check the force table
SafetyBefore believing anything the machine does. A force makes the PLC ignore reality and nothing on the machine looks different, so an unexplained behavior with a force behind it will otherwise absorb the whole visit.
Identify the exact I/O point
Rack, slot and point, or the tag name. Get this from the program rather than from the drawing where they disagree, and note that a drawing and a machine disagreeing is itself a finding worth recording.
Compare the three states: device, module LED, program bit
The Fig 9.2 move, and the one that localizes most discrete faults. All three free, all three available within a minute. Any disagreement names the link that broke; agreement means the input path is sound and the answer is in the logic or in the field device's own behavior.
Measure at the input terminal
SafetyWhere the field side and the module meet. Voltage present with the LED dark is a module channel fault; no voltage is a wiring, termination or common problem. This single measurement resolves the commonest fault in the chapter.
Check the common before condemning a module
A broken or loose common return takes out every point in its group and looks exactly like a dead card. If more than one point on the same group is misbehaving, the common is the first thing to prove, not the last.
For an output, walk the chain the other way
Bit commanded? Module LED lit? Voltage at the output terminal? Voltage at the actuator? Four questions, each eliminating one link, and the first one that answers no is where the fault is.
Treat multiple simultaneous symptoms as one cause
Several points dead together means look for what they share — a fuse, a common, a supply, a module. Investigating them individually is the single most reliable way to spend an hour on a fault that had one answer.
Remove your forces and record what you changed
SafetyBefore you leave, and before the machine is handed back. Then write down which point failed and how you proved it, because the next person's fault is often the same group.
Common technician mistakes
Reaching for the laptop before looking at the module LEDs
WhyThe program is the most sophisticated view available and it feels like the serious tool, so it gets opened first. But the LEDs answer the field-side or logic-side question in one glance and cost nothing, and going online first means you spend the visit reading logic for a fault that was a loose terminal.
Condemning a module because a group of points is dead
WhySeveral channels failing simultaneously is the natural reading of the evidence and it is almost always wrong. Independent channels do not fail together. What they share — a fuse, a common, a supply — is the fault, and it is usually a five-minute fix behind a diagnosis that sounds like a card replacement.
Leaving a force in as a repair
WhyThe machine runs, production is happy, and the intention is always to come back and do it properly. Nothing about the machine indicates the force is there, no alarm mentions it, and the next person has no reason to suspect it — which is exactly why it is one of the most dangerous things you can leave behind.
Clearing a processor fault before reading it
WhyThe instinct under production pressure is to clear the fault and see if it runs. That usually works, and it destroys the only record of what happened. Read the fault log first; it costs a minute and it is frequently the entire diagnosis.
Changing the addressing to match how it was wired
WhyWhen a program and a field wiring disagree, editing the program is the faster of the two fixes and it makes the symptom disappear. It also silently changes what the machine's documentation means, and the mismatch will be discovered by someone else in a worse situation. Fix the wiring, or change the program properly with a record.
Trusting the HMI over the I/O
WhyAn HMI shows what the program believes, which is exactly the thing under question. A screen saying a valve is open is not evidence that a valve is open — it is evidence that a bit is set. When those two can disagree, only one of them is worth walking to the machine for.
Hands-on challenge
Scenario
Line 6 — four outputs dead, and nothing else wrong
Four outputs on Line 6 stopped working at the same time during a shift. Nothing else on the machine is affected.
What you have found:
- The four are O:4/0, O:4/1, O:4/2 and O:4/3 — the first four points of one output module.
- O:4/4 through O:4/7 on the same module are working normally.
- Going online, the program is commanding all four bits on when it should.
- The module LEDs for all four are lit.
- There is no voltage at the output terminals for any of the four.
- The processor is in RUN with no faults, and the force table is empty.
Write down: what four simultaneous failures tell you before any measurement, what the module LEDs being lit proves, why this is unlikely to be four failed channels, the single measurement you would take next, and what you would do after fixing it.
Show how to approach it
The symptom list is the diagnosis here. Work out what those four outputs have in common before measuring anything.
- Four channels do not fail simultaneously. Independent failures are independent; four at once means one cause. That single inference is worth more than any measurement you could take.
- They are all on the same module and the same group. So the shared candidates are the group fuse, the group common, the field supply to that group, or the module itself.
- The program commanding the bits eliminates the logic. Chapter 8 is not where this fault lives.
- The module LEDs lighting is the decisive observation. The module has done its job — it has received the command and indicated it. The failure is downstream of the module's logic side.
- LEDs lit with no voltage at the terminals points at the output supply or its fuse, not at the module's channels. A failed module channel would generally not light its LED and take three neighbors with it.
- The measurement that settles it is voltage across the group fuse, or between the group supply and its common. Then ask why it blew — Chapter 5's principle applies to fuses everywhere.
Knowledge check
Five questions. Each is answerable by reasoning about where in the chain a signal was lost, rather than by recalling an architecture diagram.
Question 1 of 5