What is a PLC? Programmable logic controllers explained

What is a PLC? A programmable logic controller is a small, hardened computer that controls a machine or a process. It reads signals from switches and sensors, runs a program written by a controls engineer, and switches motors, valves, heaters and lamps in response, over and over, many times a second. Conveyors, packaging lines, pumps and water treatment plants run on them. This article covers what a PLC is made of, the scan cycle that makes it predictable, the languages it is programmed in, how it differs from a microcontroller, a PC, a DCS and SCADA, and how its data reaches an industrial IoT system.

Where PLCs came from

PLCs appeared at the end of the 1960s as a replacement for the relay panels that ran car plants. A production line used to be controlled by cabinets of relays wired together, and every change to the sequence meant rewiring the cabinet. A PLC does the same logic in software, so a change becomes an edit to the program.

That history still shows. The most widely used PLC language is drawn to look like a relay wiring diagram, so that electricians who knew relay panels could read it. And PLCs live where the relays lived, in a steel cabinet next to contactors and motor drives, with electrical noise, heat, dust and vibration around them, on machines that may run for decades.

What a PLC is made of

A PLC is a set of modules, even when they share one case.

The CPU module holds the processor and memory. It stores and runs the program, keeps the values of every variable, and handles timers, counters and communication.

The power supply converts mains power to the low DC voltage the controller runs on, usually 24 volts, and on smaller systems it often powers the field sensors as well.

Digital input modules read on and off signals: push buttons, limit switches, proximity sensors, photoelectric sensors, relay contacts. In most modern plants these are 24 volt DC signals. Each input is electrically isolated from the processor, typically with optocouplers, so a wiring fault or a voltage spike out on the machine stays out of the CPU.

Digital output modules switch loads on and off. Relay outputs switch AC or DC but wear with use; transistor outputs switch DC loads quickly. They drive contactor coils, solenoid valves, indicator lamps and alarm horns.

Analog input modules read continuous values from transmitters that measure pressure, level, flow, temperature and weight. The standard industrial signals are a 4 to 20 mA current loop and 0 to 10 volts; the current loop is preferred over long cable runs because it is less affected by noise and a reading of zero current shows a broken wire. Some modules accept thermocouples or resistance thermometers directly.

Analog output modules send a continuous value out: a speed reference to a variable frequency drive, or a position to a control valve.

Communication ports connect the PLC to its programming laptop, to operator panels, to remote I/O, to drives and to other PLCs. Almost every current model has Ethernet; older and smaller ones have serial ports as well.

These come in two physical forms. A compact PLC, sometimes called a brick, puts the CPU, power supply and a fixed number of inputs and outputs in one case, with room for a few expansion modules. A modular PLC mounts each module separately on a rack or a DIN rail, so the designer picks exactly the mix of I/O the machine needs and can replace one failed card. Large systems also use remote I/O: racks of modules placed near the equipment and connected back to the CPU over an industrial network.

The PLC scan cycle

A PLC runs its program in a loop called the scan. Each scan has four steps.

First, it reads the inputs. The CPU copies the state of every input terminal into an area of memory called the input image table. Second, it executes the program, from top to bottom, using the values in that table and writing its results into an output image table. Third, it writes the outputs: the output image table is copied to the output terminals, and relays and transistors change state. Fourth, it does housekeeping: servicing communication with panels and other devices, running self-diagnostics and resetting the watchdog timer. Then it starts again.

The image tables are the point of the design. Because the inputs are frozen for the length of the scan, every line of the program sees the same snapshot of the machine, and because the outputs change only at the end, the machine never sees a half-finished result. The behavior is repeatable: the same inputs always produce the same outputs, in the same order, within a known time.

A scan typically takes from under a millisecond to tens of milliseconds, depending on the size of the program and the speed of the CPU. The watchdog is a timer that the CPU must reset every scan; if the program gets stuck in a loop and the timer runs out, the PLC stops and puts its outputs in a defined safe state. The scan also sets a limit: a pulse shorter than one scan can fall between two reads and be missed. PLCs deal with fast signals through dedicated high-speed counter inputs and interrupts, and most let the engineer run some tasks, such as a PID control loop, at a fixed interval separate from the main scan.

How PLCs are programmed: IEC 61131-3

Every major PLC maker supports some or all of the languages defined in IEC 61131-3, the international standard for PLC programming. It defines the data types, the way programs are organized into programs, function blocks and functions, and five languages.

A single project often mixes them: ladder for the interlocks a technician needs to follow at three in the morning, structured text for the calculations, and a sequential function chart for the order in which the machine does things. The standard makes the concepts common across brands, but each vendor’s software adds its own extensions, so a program rarely moves from one make of PLC to another without rework. The same software can connect to a running PLC and show the live state of every contact and variable, which is how faults are traced on the floor.

PLC vs microcontroller vs PC

A PLC contains a processor, so it is fair to ask why a plant does not use a microcontroller board or a PC. A microcontroller is a chip, and a development board built around one, of the kind covered in the microcontroller comparison, is a good base for a sensor or a gadget. A PLC is the finished industrial product around a processor: isolated 24 volt I/O, a supply and enclosure rated for a control cabinet, industrial certification, a deterministic runtime, diagnostics, replaceable modules, and a programming environment the plant’s maintenance staff already know. Reproducing all of that from a microcontroller is a lot of engineering.

A PC runs a general-purpose operating system that schedules many programs at once, so it does not guarantee when a given piece of code will run. That suits an operator screen, a database or analytics, and it is a poor fit for stopping a press on time. Industrial PCs can run a software PLC, a control runtime with a real-time extension that gives it deterministic timing and the same languages.

PLC vs DCS vs SCADA

The three are often mentioned together and do different jobs.

A DCS, distributed control system, is a single plant-wide control system from one supplier, with controllers spread around the plant, one engineering database and one set of operator screens. It is the usual choice for large continuous processes such as refineries, chemical plants and power stations.

SCADA, supervisory control and data acquisition, is software that sits above PLCs and remote terminal units, often across a wide area such as a water network or a pipeline. It collects their data, shows it to operators, raises alarms, stores history and sends setpoints and commands down. The PLCs and RTUs still do the actual control; SCADA supervises them.

A PLC is the controller at the bottom of both pictures in many plants: it runs one machine or one part of a process, and it can be supervised by SCADA or sit alongside a DCS.

How PLC data reaches an industrial IoT system

Everything the PLC knows is held in named variables, usually called tags: a tank level, a motor’s running state, a cycle count, a fault code. Getting those tags out is how a PLC becomes part of the data layer described in the overview of an industrial IoT system.

The PLC’s own networks were built for the plant floor. Older installations use serial fieldbuses such as Modbus RTU over RS-485 and PROFIBUS. Current ones use industrial Ethernet protocols: Modbus TCP, PROFINET, and EtherNet/IP, which carries the Common Industrial Protocol. They are designed for a controller to talk to its I/O, drives and operator panels, and a cloud platform or historian does not speak them.

There are two ways across that gap. The first is a gateway or edge device on the plant network that reads the PLC’s tags over its native protocol, gives them sensible names and units, timestamps them, and publishes them upward, usually as MQTT to a broker or through an OPC UA server. It can send only changed values, buffer data while the upstream link is down, and process some of it on site, the trade-off the edge computing article covers. The second is to use the PLC itself: many current controllers include an OPC UA server, and some include an MQTT client, so they can publish without a separate box. How OPC UA and MQTT divide the work between them is set out in the OPC UA and MQTT article.

Direct publishing saves hardware but adds communication load to the controller and exposes it to more of the network. A gateway keeps the PLC on its own segment and gives the IT side one defined thing to talk to. That matters because several older plant protocols, Modbus among them, have no authentication: anything that can reach the port can read and write. Whichever route you take, give the IoT side read access to the tags it needs, and leave writes to the operator screens and engineering tools designed to make them.

For most projects the first step is a tag list: which tags exist, what they mean, their units and how often they change, agreed with whoever maintains the PLC program. Without it, a historian ends up full of register values nobody can interpret.