Home › Guides › PLC Basics

PLC Basics & Ladder Logic for Beginners

Before programmable logic controllers, industrial machines were controlled by cabinets full of relays, timers and miles of hardwired logic. Changing a sequence meant rewiring. A PLC replaced that cabinet with a rugged computer: the logic lives in software, so changing a sequence means editing a program, and the same hardware can run a conveyor today and a packaging line tomorrow. This guide explains what a PLC is, how it thinks in its repeating scan cycle, how its inputs and outputs work, and how ladder logic — the language that looks most like the relay diagrams it replaced — expresses control. It is written for beginners, but every concept here is one working engineers use daily. As with everything on this site, always work to your project specification and the manufacturer's instructions — those documents override any general guide.

What a PLC is, and what it is not

A PLC is an industrial computer designed for the plant floor: no fans or hard drives to fail, tolerant of electrical noise, vibration and temperature swings, and built to run one program continuously for years. Its core components are a processor (CPU) that executes the program, memory that holds the program and data, input modules that read the field, output modules that drive the field, a power supply, and communication ports for programming, HMIs and networks. Small PLCs package all of this in one brick; larger systems use racks of plug-in modules that can be expanded as a plant grows.

What a PLC is not matters too. It is not a general-purpose PC: it runs no office software, and its operating system is built for deterministic, real-time control. It is not a safety system either: safety-critical shutdowns belong to a dedicated safety PLC or hardwired safety system designed and certified for that role, not to a standard PLC, however reliable. And it is not a substitute for good field devices: a PLC can only act on the signals its instruments provide, which is why the transmitters and control valves in its loops deserve as much attention as the program itself.

Inputs and outputs: the PLC's senses and muscles

Digital inputs read on/off signals: pushbuttons, limit switches, proximity sensors, relay contacts, selector switches. A digital input module typically accepts 24 V DC (or 110/230 V AC in older panels) and reports each channel as a 1 or 0 to the program. Digital outputs drive on/off loads: contactors, solenoid valves, pilot lamps, relays. Relay outputs can switch AC or DC loads directly but wear with cycling; transistor outputs switch DC fast and silently but need external relays for heavy AC loads.

Analogue inputs read continuous signals, almost always 4–20 mA or 0–10 V, from transmitters measuring pressure, temperature, flow or level. The PLC converts the signal to a digital value — for example, a 4–20 mA input scaled to 0–100 percent or to engineering units like bar or degrees — and the program works with that number. Analogue outputs drive continuous final elements: a control valve positioner, a variable-speed drive speed reference, a modulating damper. Wiring discipline matters enormously here: analogue signals need screened cable, correct grounding, and separation from power cables, or the program will chase noise as if it were process data.

The scan cycle: how a PLC thinks

A PLC does not react instantly to anything. It runs a repeating loop called the scan cycle, and understanding it explains most beginner confusion. Each scan has four phases. First, the PLC reads all physical inputs and copies them into an input image table in memory. Second, it executes the program, rung by rung, top to bottom, using only the input image — not the live field — so that the program sees a consistent snapshot even if a field signal changes mid-scan. Third, it copies the output image table to the physical outputs. Fourth, it handles communications, diagnostics and housekeeping, then starts again.

Typical scan times are a few milliseconds, so the delay is invisible in most processes — but it is real, and it matters in fast applications. A pulse shorter than one scan may be missed entirely. An output that changes state several times within one program execution will only show its final state at the end of the scan. And a program that depends on the order of rungs will behave differently if rungs are reordered, because rungs execute in sequence, not simultaneously. Engineers who understand the scan cycle debug faster, because they stop asking "why didn't it react instantly?" and start asking "what did the program see at scan time?"

Ladder logic: rungs, contacts and coils

Ladder logic is drawn like a relay ladder: two vertical power rails, with horizontal rungs between them. Each rung is a rule: if the conditions on the left are true, then energise the output on the right. The symbols deliberately mirror relay hardware so that electricians could read the first PLC programs without learning a new language — and that readability is why ladder remains the dominant PLC language decades later.

The basic elements are few. A normally open (NO) contact is true when its input is on; a normally closed (NC) contact is true when its input is off — the classic use is a stop button wired normally closed, so a broken wire stops the machine instead of leaving it running. Contacts can be combined in series (AND: all must be true) or in parallel (OR: any one true). A coil on the right of a rung represents an output: when the rung is true, the coil energises. Internal coils, often called internal relays or memory bits, store intermediate results without driving a physical output. That is the whole grammar, and everything else in ladder logic is built from it.

The most important pattern is the seal-in (latching) circuit, the software equivalent of a motor starter's holding contact. A start pushbutton in parallel with a contact of the motor's own output means the motor keeps running after the operator releases the button, until a stop condition breaks the rung. Beginners should master this one pattern before anything else: it appears in almost every real program, and getting its stop logic wrong — forgetting an emergency stop, an overload trip, or a permissive — is how unsafe programs are written.

Timers and counters

Real control needs time and counting, and ladder provides both as function blocks. An on-delay timer (TON) starts timing when its input goes true and turns its output on only after the preset time has elapsed; drop the input and it resets. It is used for start-up delays, dwell times and debounce. An off-delay timer (TOF) keeps its output on for a preset time after its input goes false — the classic use is a cooling fan that keeps running after a motor stops. A retentive timer (RTO) accumulates time across multiple input pulses without resetting, for totalised run-time measurement.

Counters count events. A count-up counter (CTU) increments each time its input pulses and turns on when it reaches its preset; a count-down counter works in reverse. Counters track bottles on a conveyor, strokes of a press, or batches completed, and a reset input returns them to zero. Timers and counters each have three associated values worth knowing: the preset (the target), the accumulated value (where it is now), and the done bit (whether it has reached its target). Reading those three values in online monitoring is how engineers debug timing problems without guessing.

Worked example: a motor start/stop station

Consider a conveyor motor with a start pushbutton, a stop pushbutton, a motor overload relay contact, and an emergency stop, all wired to digital inputs, driving a motor contactor output. The ladder has one main rung. In series from left to right: the emergency stop contact (normally closed, so the rung breaks on emergency), the overload contact (normally closed, breaking on trip), and the stop pushbutton (normally closed). Then a parallel branch: the start pushbutton (normally open) in parallel with a contact of the motor output itself — the seal-in. Then the motor coil.

Trace it: with everything healthy, pressing start makes the rung true through the start branch, energising the motor coil. The seal-in contact closes, so releasing start keeps the rung true through the seal-in branch. Pressing stop, tripping the overload, or hitting the emergency stop breaks the rung, the coil drops out, the seal-in opens, and the motor cannot restart until start is pressed again — it cannot restart itself when the fault clears, which is exactly the behaviour a safe design requires. Add a second rung with a run lamp driven by the motor output, a third with a TON timer that delays a downstream conveyor by five seconds after this one starts (a sequenced start that limits inrush), and you have a complete, realistic small program in three rungs. That is ladder logic: simple elements, combined carefully, with safety thought through before convenience.

From ladder to the wider control world

Ladder is one of five languages in the IEC 61131-3 standard. Function block diagram (FBD) suits continuous control and PID loops. Structured text (ST) suits calculations and data handling. Sequential function chart (SFC) suits step-by-step sequences like batch recipes. Instruction list has largely been replaced by structured text. Most real projects mix languages: ladder for interlocks and motor control, function blocks for analogue control, structured text for calculations. Choosing the right language per task is a mark of experience, not disloyalty to ladder.

Beyond a single PLC, the program sits in a larger architecture: PLCs exchange data with each other and with supervisory systems over industrial networks, and operators watch and command the plant through HMIs — the subject of our guide to SCADA systems. The field devices on the PLC's inputs and outputs are covered in our guides to instrumentation transmitters and control valves, and the electrical protection context in our transformer testing guide. Learn ladder first, then learn the system around it.

Common beginner mistakes

Most early PLC mistakes are conceptual, not syntactic. Using a normally open contact where a normally closed one is needed for a stop or a safety input, so a broken wire leaves the machine running. Forgetting that outputs only update at the end of the scan, and writing programs that expect instant feedback. Using the same output coil in two different rungs, so the last rung executed wins and the first is silently ignored. Leaving a timer's preset in the wrong timebase (tenths of a second versus seconds — a classic factor-of-ten error). And the most dangerous: writing a program that restarts equipment automatically when a fault clears, instead of requiring a deliberate restart. Every one of these is caught by a habit worth building early: before downloading any program, trace each rung by hand with inputs on and off, and ask "what happens on power failure, on wire break, and on fault reset?" If any answer is "it restarts by itself", fix it before it reaches the plant.

Frequently asked questions

Written by Abdul Wadood, electrical site engineer — instrumentation and control, testing and commissioning. Educational content only; always follow your project specification and manufacturer instructions.