PLC vs. Edge Computer: Which Belongs in Your Automation Project?

The PLC vs. edge computer question has a cleaner answer than vendors make it sound: the PLC owns anything that moves, times, or protects the machine, and the edge computer owns anything that stores, computes, or talks to the outside world. A PLC buys you deterministic scan cycles and I/O built to live in an electrical panel for twenty years. An edge computer buys you Linux, real programming languages, and cheap compute. Most projects beyond trivial size end up with both, doing different jobs, connected over Ethernet.

What a PLC guarantees that Linux does not

A PLC runs a scan cycle: read every input, execute the logic top to bottom, write every output, repeat. On typical hardware that loop completes in 1 to 10 milliseconds, and the worst case is bounded and supervised by a hardware watchdog that faults the controller into a safe state if the loop ever overruns. That bound is the whole product. When a sensor sees a jam, the diverter fires within a known number of milliseconds, every time, on the ten-millionth cycle the same as on the first.

A general-purpose Linux system makes no such promise. The scheduler optimizes for throughput, so your control process can be preempted for tens of milliseconds by disk flushes, log rotation, a network storm, or an unattended package update, and none of those events announce themselves. The PREEMPT_RT kernel work is genuinely good and can hold worst-case latencies under a millisecond on carefully configured hardware, but "carefully configured" is doing heavy lifting in that sentence, and no one certifies your particular stack of kernel, drivers, and application code.

The hardware gap is just as real. A PLC runs on 24 VDC panel power with brownout ride-through, offers isolated and protected I/O that shrugs off the miswiring that would kill a hobby board, is rated for roughly -20 to +60 degrees C in a sealed cabinet, contains no fans and no wear-prone storage, and carries decades of field MTBF history. And there is the human factor: PLC logic in ladder can be watched executing live by a maintenance electrician at 2 a.m., without you on the phone. That one property settles more architecture arguments than any spec sheet.

What an edge computer does that a PLC cannot

PLCs are miserable at everything that is not control. String handling is clumsy, memory is measured in megabytes, storing history means fighting proprietary data logging add-ons, and TLS support on anything more than a few years old ranges from limited to absent.

An edge computer eats those jobs. It translates protocols, pulling registers over Modbus TCP or tags over OPC UA and republishing them as MQTT. It buffers data through internet outages with store-and-forward instead of dropping it. It runs a real database, serves a local dashboard to any browser on the plant network, executes Python, hosts containers, and runs vision or anomaly-detection inference that no PLC could touch. Per unit of compute and per gigabyte of storage, the comparison is not close. The broader case for putting compute next to the machine is laid out in edge computing explained for manufacturing.

As a hypothetical that comes up constantly: a shop wants OEE numbers and power monitoring from a fifteen-year-old line. The PLC already has most of the signals, but getting them into a dashboard through the PLC alone means wrestling brand-specific historian licenses. A fanless edge box beside the panel polls the PLC over Ethernet, computes availability and rate, serves the dashboard, and pushes a summary to the cloud. The PLC never knows anything changed, which is exactly the point.

Can an edge computer replace a PLC?

Sometimes, but be precise about what that means. Soft PLC runtimes such as CODESYS turn an industrial PC into a controller with a real-time runtime and proper fieldbus I/O, and they work well. That path amounts to buying a PC-shaped PLC, not running machine control from a Python script on stock Ubuntu, which is a different and worse idea.

Three tests sort it out. First, if a late output can damage equipment or product within milliseconds, the logic belongs on a PLC or a certified soft PLC runtime. Second, safety functions are not negotiable: e-stops, light curtains, and guard interlocks must run through safety-rated hardware evaluated to ISO 13849 or IEC 62061, and a general-purpose Linux box never qualifies regardless of how well it is programmed. Third, ask who fixes it at 2 a.m. If the answer is an electrician who knows ladder, that answers the question for you.

For pure monitoring with no outputs that move anything, the calculus relaxes considerably, and even a hardened Raspberry Pi can be a legitimate tool. We wrote about where that line sits in Raspberry Pi in manufacturing.

PLC vs. edge computer: the architecture that usually wins

The pattern that keeps working is unglamorous. The PLC runs the machine, full stop. The edge computer sits beside the panel with read access to the PLC over OPC UA, Modbus TCP, or EtherNet/IP, and handles analytics, buffering, dashboards, and cloud connectivity. The failure modes then isolate cleanly: if the edge box dies, the machine keeps producing and you lose only telemetry until it is replaced. Preserving that property takes discipline, because it is tempting to let line-critical logic creep onto the convenient Linux box. Resist that unless it is a deliberate, documented decision.

Two pieces of hygiene make the marriage durable. Put the edge computer on a segmented network with a firewall between the machine network and the office network, with read-only PLC access wherever possible. And if the edge side must write anything back, such as a recipe setpoint, route it through a defined handshake block in the PLC that range-checks every value, so the PLC remains the final authority on what the machine is allowed to do.

What do they cost, and how do they fail?

Hardware is the cheap part either way, and these brackets swing with brand and I/O count. A micro PLC runs roughly $150 to $700, a mid-range controller with expansion I/O and an HMI more like $1,500 to $5,000 in parts, and big-name rack systems climb quickly from there. A fanless industrial edge PC runs about $400 to $2,500, and a Pi-class board lands near $100 to $250 once you add an industrial enclosure and a proper supply. Engineering time dwarfs all of it, which is why the architecture decision matters more than the hardware line items.

Failure modes differ in character. PLCs die of power supplies, worn relay output contacts, and corroded terminals, and essentially never of software rot. Edge computers die of SD and eMMC wear from relentless logging, clogged fans, thermal throttling inside a sealed panel in July, filesystem corruption from power loss, and updates nobody scheduled. Every one of those has a known countermeasure: industrial-grade flash or an SSD, fanless designs, honest thermal budgeting, a read-only root or journaled filesystem with a small UPS, and pinned software versions with staged updates. None of it is hard. All of it must be designed in rather than patched in.

A short decision list to close the loop:

• Motion, interlocks, or anything a person can touch: PLC, with safety functions on safety-rated hardware
• Timing that must repeat within milliseconds: PLC
• Storage, dashboards, cloud, protocol translation, vision, analytics: edge computer
• Monitoring-only project with no control outputs: an edge computer alone is fine
• Existing machine that needs data out: add an edge computer beside the PLC, and do not rip out what works

FAQ

Do you need both a PLC and an edge computer?

For anything that combines machine control with data collection or connectivity, usually yes, because each is poor at the other's job. Monitoring-only projects can often skip the PLC, and simple standalone machines with no data requirements can skip the edge computer.

Is a Raspberry Pi good enough for production automation?

For monitoring and data collection, a hardened Pi with industrial flash, a proper enclosure, and a watchdog can serve well. For controlling machinery it is the wrong tool: no deterministic guarantees, no protected I/O, and no path to safety compliance.

What is scan-cycle determinism and why does it matter?

It is the guarantee that the controller reads inputs, executes logic, and writes outputs within a bounded, supervised time, typically single-digit milliseconds. It matters because physical processes do not wait: a response that is occasionally 50 milliseconds late means jams, scrap, or worse, even if the average looks fine.

Can a PLC send data to the cloud without an edge computer?

Recent PLCs with MQTT or OPC UA support can, within limits: small payloads, shallow buffering through outages, and awkward certificate management. That works for a handful of tags, and beyond that an edge computer pays for itself quickly.

Willowark builds this split regularly: PLC control where determinism matters and edge compute where the data lives, as part of our industrial automation services. If you are deciding what belongs where on your project, reach out and we will help you draw the line before hardware gets ordered.