PLC Programming for Complete Beginners

A digital input reads one of two states: ON or OFF (also called 1/0, TRUE/FALSE, or High/Low). A pushbutton, a limit switch, a proximity sensor — anything that's simply "triggered or not" connects to a digital input. A digital output is the same idea in reverse: the PLC turns something ON or OFF — a motor starter coil, an indicator light, a solenoid valve.

This describes which direction current flows through an input or output, and it's the single most common point of confusion for anyone new to industrial wiring.

Every switch, sensor, or pushbutton has a "resting" state before it's triggered — this is what NO/NC describes, and it matters enormously for both wiring and logic design.

When the button is pressed, it completes the circuit from 24V, through the button, into Input 1 — the module reads that as ON. Release the button, the circuit opens, the module reads OFF. Every digital input works on this same basic principle, regardless of the specific sensor or switch involved.

A ladder logic program is drawn to look like a ladder: two vertical lines (the rails) representing power and ground, with horizontal rungs connecting them — each rung is one independent piece of logic, evaluated top to bottom, every scan cycle.

Electricians already read relay diagrams this way — ladder logic was designed deliberately to feel familiar to someone who already understood relay control panels, which is exactly why it became the dominant PLC language.

A contact doesn't control power itself — it represents a condition being checked. "Is this input ON?" (Normally Open contact) or "Is this input OFF?" (Normally Closed contact). If the condition is true, that contact "passes power" along the rung, continuing to the next element.

A coil sits at the end of a rung and represents the actual output — either a real physical output (a light, a motor starter) or an internal memory bit used elsewhere in the program.

How contacts are arranged on a rung directly maps to logical AND/OR — exactly like circuit theory.

This single pattern is one of the most common circuits in all of industrial control — it appears constantly starting in Module 8's motor control circuits.

Pressing Start energizes the Motor coil. The Motor's own contact (wired in parallel with Start) also closes at the same moment — so even after you release the Start button, that parallel contact "seals in" the circuit, keeping the motor running. Pressing Stop breaks the circuit entirely, dropping the seal-in along with it.

The most common timer type. Starts counting the moment its input goes true; once the preset time elapses, its Done (DN) bit turns ON. If the input goes false before the preset is reached, the timer resets to zero.

The mirror image of TON. The DN bit turns ON immediately when the input goes true, and stays ON for the preset duration after the input goes false — useful for "keep something running a little longer after the trigger stops," like a cooling fan.

Like a TON, except the accumulated time is not reset when the input goes false — it holds its progress and resumes counting next time the input goes true again. Requires a separate explicit "reset" instruction to zero it out. Used for things like tracking total accumulated run-time toward a maintenance interval, across many separate on/off cycles.

A real, common pattern: count 10 boxes onto a pallet, then pause 5 seconds (to let a wrapper machine finish), then reset and start the next pallet.

A digital signal is one of two states — on or off. An analog signal is a continuously variable value — a tank's water level isn't "full or empty," it's anywhere from 0% to 100%. Analog inputs/outputs read and write these continuous values, most commonly using one of two standard signal ranges.

An analog input module doesn't directly store "4-20mA" — it converts the incoming signal into a raw digital number, typically over a range like 0-32767 (a common 15-bit resolution). The PLC program then has to convert that raw number into an actual engineering value (like degrees, PSI, or gallons) — this conversion is called scaling.

Scaling maps one range of numbers onto another — the raw count range onto the real-world engineering unit range.

Worked example: a pressure transmitter reads 4-20mA, scaled by the analog module into raw counts 0-32767. The transmitter is rated for 0-150 PSI. If the current raw reading is 16,384 (roughly the midpoint):

Analog outputs work the same way in reverse — the program calculates a desired real-world value (like "run this valve 60% open"), scales it back down into a raw count, and the output module converts that into an actual 4-20mA or 0-10V signal driving the physical device (often a variable speed drive or a proportional valve).

• Be specific and consistent — Conveyor1_MotorRunning beats M1 for anyone maintaining the program later, including future-you.
• Group related tags with a shared prefix — Tank1_Level, Tank1_HighAlarm, Tank1_LowAlarm makes it obvious at a glance which equipment a tag belongs to.
• Match physical labels where possible — if the wiring diagram calls a device "PB-101" (pushbutton 101), naming the tag PB101_Start keeps the software and the physical panel traceable to each other.

A single flat ladder program thousands of rungs long is nearly impossible to navigate, test, or safely modify. Real PLC programs are broken into routines (sometimes called programs or subroutines depending on platform) — each one handling one specific piece of equipment or one specific job, called from a main routine that coordinates them.

Ladder Logic isn't the only PLC programming language — it's one of five standardized languages defined by IEC 61131-3, the international standard nearly every PLC platform follows in some form.

The same conveyor gate-delay example from Module 4, written in Structured Text instead of ladder — notice how much more naturally a mix of conditions and math reads as text versus as rungs.

IF ConveyorRunning THEN
    GateDelayTimer.TON(IN := TRUE, PT := T#3s);
ELSE
    GateDelayTimer.TON(IN := FALSE, PT := T#3s);
END_IF;

IF GateDelayTimer.Q THEN
    DischargeGate_Open := TRUE;
END_IF;

A PLC's digital output is only rated for a small current — enough to energize a relay coil, not enough to directly handle a motor's actual running current. Instead, the PLC output energizes a motor starter (a large relay/contactor plus overload protection), and the starter's much heavier-duty contacts handle the motor's real current.

A motor starter includes overload relays — devices that monitor the actual current the motor is drawing and trip the circuit if it draws too much for too long (a sign of a jammed mechanism, a failing motor, or a mechanical overload). This protects the motor from burning out, and the overload's own contact is typically wired directly into the motor's stop circuit — hardware-level protection that works even if the PLC program has a bug.

This is Module 3's seal-in rung, now with real motor control components labeled:

Notice the overload relay's contact is wired the same way as the Stop button — Normally Closed, in series. If the overload trips (motor drawing too much current), that contact opens exactly like someone pressed Stop, and the motor shuts down.

For motors that need variable speed rather than just on/off, a VFD sits between the motor starter and the motor, controlling the motor's speed by varying the frequency of the power sent to it. The PLC typically controls a VFD one of two ways:

A PLC program can have bugs. A PLC can freeze, lose power unexpectedly, or run corrupted logic. Because of this, safety-critical functions — emergency stops, guard door interlocks, light curtains — are built using dedicated hardware safety circuits that work independently of whether the PLC's program is even running correctly at all.

An E-stop is a Normally Closed, mushroom-head pushbutton (Module 2's fail-safe principle, applied at its most critical) wired directly into a hardware safety circuit — pressing it physically breaks the circuit supplying power to the hazard, immediately, regardless of what the PLC program is doing.

A safety relay is a specialized relay built specifically for safety circuits, often monitoring TWO independent contacts for every safety input — if those two contacts ever disagree with each other, the safety relay assumes a fault has occurred and trips to the safe state, rather than guessing which one is correct.

Machine safety standards (like ISO 13849) define Categories and Performance Levels describing how robust a safety circuit needs to be, based on the severity and likelihood of the hazard it's protecting against. This is genuinely deep, certification-level territory — the key beginner takeaway is simply that not every safety circuit needs to be built identically; the required level of redundancy and monitoring scales with how dangerous the specific hazard actually is.

An HMI (Human-Machine Interface) is the screen an operator uses to monitor and control a process — start/stop buttons, live readings (tank levels, temperatures, speeds), alarms, and setpoint entry. It's a separate device from the PLC, communicating with it over a network connection (Module 11) to read and write the same tags the ladder program uses.

An HMI screen doesn't run its own independent logic — every button, gauge, and indicator on the screen is bound directly to a PLC tag. Pressing an HMI "Start" button writes TRUE to a tag; the ladder program's Start rung reads that exact same tag, same as if a physical button had been pressed.

An HMI's alarm system watches specific tags against defined limits (e.g., "Tank1_Level below 10%") and displays an alert when the condition is true — often with a log of every alarm's time, description, and whether it's been acknowledged by an operator. Good alarm design deliberately limits how many alarms can fire at once; a screen flooded with 200 simultaneous alarms during a real emergency is far less useful than a screen showing the 3 that actually matter right now.

• Match the physical layout — if Tank 1 is physically on the left side of a building, put it on the left side of the overview screen too. Operators build a mental map that should match reality.
• Use color deliberately, not decoratively — red should consistently mean "problem," green "running/good," rather than colors chosen for visual appeal that end up meaning different things on different screens.
• Show what matters, hide what doesn't — an overview screen with 40 dense data points is harder to act on quickly than one showing the 5 numbers that actually drive a decision, with detail screens available a tap away.
• Confirm destructive actions — stopping a whole production line or resetting a batch should require a confirmation step, not a single accidental tap.

A single machine rarely stands alone — a PLC typically needs to talk to an HMI (Module 10), other PLCs controlling adjacent equipment, and often a central SCADA (Supervisory Control and Data Acquisition) system giving plant-wide visibility. Communication protocols are the agreed-upon rules that let all of this talk to each other reliably.

Modbus is worth understanding in a bit more detail since it's so widespread. It organizes data into simple numbered registers — a device (the "slave"/"server") holds data at specific register addresses, and a controller (the "master"/"client") reads or writes those registers.

Ethernet-based industrial protocols use the same IP addressing concepts from general networking — every PLC, HMI, and networked device gets its own IP address on the plant network. Industrial networks are very commonly segmented (kept physically or logically separate from the general office network) specifically for security and reliability — a problem on the office network shouldn't be able to affect production equipment, and vice versa.

Every PLC programming platform has an "online" or "monitor" mode — connecting a laptop to the running PLC and watching the actual ladder logic execute in real time, with every contact and coil highlighted to show its current true/false state. This is the single most powerful troubleshooting tool available: instead of guessing what the program is doing, you watch it happen.

1. Check the physical machine first — is there an obvious mechanical jam, a tripped overload, a door interlock open? Many "PLC problems" are actually simple physical/electrical issues.
2. Check field device power — does the sensor/switch actually have power? A surprising number of "broken sensor" calls are actually a blown fuse or a loose terminal.
3. Check the physical input LED on the PLC module — most input/output modules have small indicator LEDs showing each point's current state, independent of the program. If the input LED isn't lighting when it should, the problem is upstream of the PLC program entirely (wiring, the sensor itself, power).
4. Go online and monitor the actual rung — if the input LED is correct but the expected output still isn't happening, the issue is in the logic itself — trace power flow through the rung as described above.
5. Check the output LED and the field wiring beyond it — if the program is correctly energizing the output but the physical device still isn't responding, the problem has moved back out to the field wiring or the device itself.

A small sorting station: boxes arrive on a conveyor. A sensor detects each box. A second sensor (a simple height/weight-style "reject" sensor) flags bad boxes. Good boxes continue to the end; bad boxes get pushed off onto a reject line by a pneumatic pusher. The system tracks how many boxes have passed, pauses briefly for the pusher to cycle, and can be stopped instantly at any time.

Every real PLC project starts with a documented I/O list before a single rung is written — directly applying Module 6's tag naming discipline.

Directly from Modules 3 and 8, with the E-stop added as an additional Normally Closed condition in series — anywhere along this chain going false stops the conveyor immediately.

Only count a box as "good" if it triggered the box sensor but not the reject sensor — Module 3's series/AND logic combined with a Normally Closed contact acting as a NOT condition.

Directly applying Module 4's TON pattern — the reject sensor triggers the pusher, and a timer holds it extended just long enough to push the box off, then automatically retracts it.

Applying Module 10's principles: an overview screen showing conveyor running/stopped status (color-coded, matching Module 10's "red means problem" convention), the live BoxCount, a Start and Stop button bound to the same tags the ladder logic reads, and an alarm tile that lights if EStop is ever tripped.