Control Circuits & Ladder Logic

Ladder logic is a drawing of a control circuit that turned into a programming language, and it kept the drawing's conventions on the way. That is why it looks like a circuit and reads like a sentence.

Two vertical rails carry the supply. Between them, each horizontal rung is one statement: a set of conditions on the left, and one thing that happens on the right if all of them are satisfied.

"If the stop is not pressed and the guard is closed and the overload is healthy and somebody has pressed start — run the conveyor."

That is a rung. Reading them aloud is the skill this chapter is about, because a technician who can read a rung as a sentence can find out which word is false in about a minute, and one who cannot is reduced to swapping parts.

Hardwired and programmed are the same convention

Chapter 5's starter used relay logic on real wire. A PLC does the same thing in software, scanning the rungs and deciding which outputs to energise. The symbols, the left-to-right reading, and the series-is-AND / parallel-is-OR rules from Chapter 3 are identical in both.

The difference that matters on a callout is that you can see a hardwired circuit with a meter and you need a laptop or an HMI to see a programmed one — and that safety functions are frequently kept hardwired or on a dedicated safety controller precisely so they do not depend on software.

The symbol is a question, not a picture

This is the most misread thing in ladder logic, and it costs hours.

A contact symbol in a program does not describe the physical device. It describes what the program is asking about the bit:

• Examine if closed (─┤ ├─) is true when the bit is true.
• Examine if open (─┤/├─) is true when the bit is false.

So a stop button — normally closed in the field, passing 24 V until somebody presses it — appears in the rung as ─┤ ├─, because the program wants to know whether that input is present. It looks like a "normally open contact" and it is nothing of the sort. Same for an overload's healthy contact and for most safety devices, all of which are NC in the field for the fail-safe reasons in Chapter 7.

The rule that saves you: read the field device and the instruction as two separate facts, and check they agree. A device that is NC in the field and examined-if-closed in the program is the normal, correct, fail-safe arrangement.

Permissives, interlocks, and why the distinction is diagnostic

A permissive must be true for the machine to start. A interlock must stay true for it to keep running. Structurally they are the same thing — a contact in series with the output — but they fail differently and the reports sound different:

• "It will not start" — any condition in the rung could be false, including the momentary one.
• "It started and then stopped" — something that was true became false, which means an interlock. The start button is irrelevant, and so is anything else that only mattered at the moment of starting.

That single distinction halves the search on most control faults, and it comes free with the operator's description.

The seal-in

A start button is momentary: true for the fraction of a second somebody's thumb is on it. Something has to hold the output on afterwards, and that something is the output's own contact wired in parallel with the button — the seal-in.

The failure signature is unmistakable once you know it: the machine runs while the button is held and stops the instant it is released. Everything else in the rung is working; the thing holding it in is not. On a hardwired starter that is an auxiliary contact or its wiring; on a PLC it is the seal-in branch or the bit it references.

Where else is this bit used

A coil in one rung is a contact in twenty others, and this is where control faults get genuinely difficult.

The tool is cross-referencing: for any bit, the software will list every rung that reads it and every rung that writes it. Two habits follow from that. First, when a condition is false, cross-reference it to find where it is written and go there. Second, be suspicious of any output written in more than one place — with a normal scan, the last rung to write it in that scan is the one that wins, and a bit set in one rung and cleared in another produces behaviour that looks impossible from either rung alone.

Latches, timers, and the things that outlive a power cycle

Latch and unlatch instructions set a bit and leave it set — including through a power cycle or a mode change, because the bit is retained. That is occasionally what you want and frequently a trap: a machine that comes back from a power failure in a state nobody expects usually has a latch in it.

Timers produce the other classic. A timed-on delay holds a condition false for its preset before allowing the output, so a rung that reads correctly can still produce "it works, but half a second late" or "it drops out after exactly thirty seconds". If a fault has a consistent, repeatable duration attached to it, look for a timer before anything else.

1. Get the symptom precisely: will not start, or started and stopped

   These are different faults with different search spaces, and the operator already knows which one it is. "Will not start" opens the whole rung; "started and then stopped" means an interlock and eliminates the permissives and the start button outright.

2. Find the output, and read its rung aloud as a sentence

   Name the output first — the contactor, the valve, the drive enable — then read the conditions in order as one "if… and… and… then" statement. Doing it out loud is not a joke; it forces you to name every condition rather than skimming the ones you assume are fine.

3. Identify which condition is false

   Online, the true conditions are highlighted and the false one is not, which turns this into looking rather than deducing. On a hardwired circuit it is the Chapter 3 method instead: measure across each device in turn and find the one holding the supply voltage.

4. Cross-reference that condition to where it is written

   The false bit is rarely the answer — it is a pointer. Find every rung that writes it and follow the chain until you arrive at something physical: an input, a device, a machine state. Most control faults are three or four hops from the symptom.

5. Decide whether you are now field-side or logic-side

   Once the chain reaches an input bit, the question changes: is the field device actually doing what the input says? That is Chapter 9's territory, and it is the point where a meter beats a laptop.

6. Confirm the field device and the instruction agree

   Physical NO or NC, against examine-if-closed or examine-if-open. Check this whenever a part has been replaced or a circuit modified, and check it before concluding that a plainly working device is being ignored.

7. Check the force table before believing anything

   Safety

   A force makes the PLC ignore reality, and nothing on the machine looks different. Check for forces early, treat any you find as a finding rather than a nuisance, and remove your own before you leave.

8. Fix the cause, not the rung

   Changing logic to make a symptom disappear is nearly always converting a field fault into a permanent one, and it removes a protection somebody put there deliberately. If the logic genuinely is wrong, that is a change with its own authorisation, review and record — not something done at 3 a.m. to get a line running.

• Reading the contact symbol as a picture of the device

  Why

  ─┤ ├─ looks exactly like a normally-open contact, and for a great many bits it effectively behaves like one, so the misreading survives for years without being contradicted. Then it meets a stop button or an overload contact — NC in the field, examine-if-closed in the program — and the technician concludes the drawing is wrong.

• Editing the program to make the symptom stop

  Why

  It works immediately and it feels like the sophisticated option. But a permissive that is false is usually false for a reason, and deleting it removes somebody's deliberate protection while leaving the original fault in place. It also produces a machine that no longer matches its documentation, which is the next person's problem.

• Leaving a force on

  Why

  Forcing is how you prove a theory quickly, and the intention is always to remove it. The reason it gets left is that the machine then works, the pressure comes off, and nothing about the machine looks any different. Nothing you can leave behind on a plant is more dangerous relative to how invisible it is.

• Assuming the rung in front of you is the only one writing that output

  Why

  You found the rung, the rung explains the behaviour, and the search stops. But an output written in two places resolves by scan order, and the result matches neither rung read on its own. Cross-reference before concluding that the PLC is behaving impossibly.

• Bypassing an interlock to 'see if that's the problem'

  Why

  It is a genuinely informative test and that is the seduction. It is also removing a protection on a machine that is about to move, usually while somebody is standing where the interlock exists to protect them. If the test is truly necessary it needs the Chapter 1 treatment — authorisation, PPE, a second person, and everyone clear.

• Blaming the PLC

  Why

  Processors and I/O cards do fail, and they fail far less often than everything attached to them. Reaching for that explanation early means the field device, the wiring, the mechanical condition and the force table all go unexamined — and it is a diagnosis nobody can act on at three in the morning anyway.

Five questions. Each is answerable by reasoning about how a rung behaves rather than by recalling a symbol table.