Getting Data Out of PLCs: Protocols, Gateways, and Practical Options

Getting data out of PLCs comes down to three decisions: which protocol the controller speaks (Modbus RTU or TCP, Ethernet/IP, Siemens S7, or OPC UA), what sits between the PLC and your database (a Kepware-class OPC server, a hardware protocol gateway, or an edge device publishing MQTT), and where the data finally lands (a historian, a time-series database, or a cloud platform). Almost every PLC made in the last thirty years can be read without modifying its program, and the hardware to do it typically costs $200 to $2,000 per line.

The PLC in your panel already knows almost everything you want: part counts, cycle states, fault codes, temperatures, speeds. PLC data collection is the discipline of getting those values out without disturbing the machine, and it's more about choosing well than about any single hard step. Here's how a practicing integrator actually walks through it.

First, Figure Out What You're Actually Talking To

Before protocols, take inventory. For each controller, note the brand and CPU model, the firmware vintage, and the physical ports: Ethernet, RS-232/485 serial, or a proprietary connector like Allen-Bradley DH+. This one-page survey determines everything downstream, and skipping it is how projects discover in week six that the "networked" PLC is a 1998 SLC 5/03 with one serial port already occupied by an HMI.

Also locate the program files and documentation. You can read a PLC without its program, but you can't interpret register N7:42 without knowing what the programmer put there. If the program is lost or password-locked, budget time for recovery or plan to infer meaning by watching values change against known machine behavior. Tedious, but doable, and cheaper than guessing.

One more early question: does your controls network even reach IT's network? Many plants have PLCs on an isolated machine network, which is often correct for security. The standard answer is a dual-homed edge device or a firewall with narrow rules, so data flows out while nothing flows in. Decide this deliberately rather than discovering it as a crisis.

Which PLC Protocols Actually Matter?

You'll encounter perhaps six protocols in the wild, and knowing their personalities saves a lot of grief.

Modbus is the cockroach of industrial protocols: everywhere, simple, and unkillable. Modbus RTU runs over serial (RS-485 handles long multi-drop runs; RS-232 is point-to-point), while Modbus TCP is the same register model over Ethernet. It has no data types beyond 16-bit registers and no security to speak of, and it will still be running when the sun burns out. VFDs, power meters, and older PLCs speak it fluently.

Ethernet/IP is the native tongue of Allen-Bradley's CompactLogix and ControlLogix families, and it lets you read tags by name, which is a genuine quality-of-life improvement over register numbers. Siemens S7 controllers have their own protocol (with newer models speaking OPC UA directly), and every major brand has its equivalent.

OPC UA is the vendor-neutral standard the industry settled on for structured, secure data exchange: typed data, browsable namespaces, certificates. Newer PLCs often embed an OPC UA server, and it's what MES and historian vendors expect to consume.

MQTT is the odd one out because it isn't a PLC protocol at all; it's a lightweight publish/subscribe transport that edge devices use to move data northward. The pattern you'll see everywhere now: something speaks Modbus or Ethernet/IP to the PLC, then publishes MQTT (often with the Sparkplug B convention) to a broker. PLCs are polled locally; the rest of the architecture subscribes.

Do You Need an OPC Server, a Gateway, or Neither?

This is the architecture fork, and the honest answer depends on scale and appetite.

The classic route is a Kepware-class OPC server: commercial software (KEPServerEX, Matrikon, and peers) on a plant PC with driver licenses for each protocol family, translating everything into OPC UA for consumption by SCADA, historians, or custom clients. It's mature, supported, and handles ugly protocol corners you'd rather not learn about. Licensing typically runs $1,000 to $5,000 or more depending on drivers and tag counts. For a plant with many PLC brands and an existing SCADA culture, it's often the sane default.

The hardware gateway route puts a small box ($200 to $700, from vendors like Red Lion, HMS/Anybus, or Moxa) at each machine, speaking the PLC's protocol on one side and Modbus TCP or MQTT on the other. Gateways shine for serial-era controllers and for keeping each machine's integration self-contained. No PC, no OS patching, very little to break.

The open edge route runs software like Node-RED or a purpose-built collector on an industrial edge PC, using open driver libraries to poll PLCs directly and publish MQTT. Up-front cost is low and flexibility is high; the trade is that you own the maintenance. For shops with any software capability in-house, or a partner who provides it, this route has become very common, and it's frequently where our systems integration work lands.

Mix freely. A gateway on the crusty serial PLC, direct Ethernet/IP polling on the modern lines, one broker collecting it all: that's a normal, healthy architecture, not a compromise.

Polling Without Hurting Anything

A few field-earned rules. Poll at the rate the question requires, not the rate the network allows: once per second is plenty for states and counts, and once per minute is fine for temperatures. Old CPUs service communications in slack scan time, so an aggressive poll on a loaded PLC-5 can measurably stretch scan times; read a small, contiguous block gently and you'll be invisible.

Prefer reading over writing, and if the project only needs collection, configure write access off entirely at the gateway or firewall. A data collection system that can write to controls is a liability you don't need to carry. And log communication health itself (poll success rates, response times), because the first symptom of a failing switch or a flaky serial line is usually a data gap somebody blames on the software.

Buffer at the edge. Good gateways and edge nodes store-and-forward through network outages, which turns "the Wi-Fi dropped for an hour" from a data loss event into a non-event.

Where the Data Lands: Historians and Their Descendants

Collected data needs a durable home, and the choice shapes what you can do later.

The traditional answer is a process historian (OSIsoft PI, now AVEVA, Canary, Proficy and kin): purpose-built time-series storage with industrial compression, trend tools, and enterprise price tags, typically five figures and up. In larger plants they're the institution and integrating with one is often the requirement, not the question.

The newer answer is open time-series databases (InfluxDB, TimescaleDB) fed over MQTT, visualized with dashboard tooling, at a fraction of the license cost. For a small manufacturer starting fresh, this stack typically does everything needed for monitoring, downtime tracking, and OEE at modest cost, and it doesn't lock the data into anyone's format. Whichever you pick, insist on this property: you can get your own data out, in bulk, without a vendor's permission. Ten years of process history is an asset; make sure you own it.

For machines with no PLC at all, none of this is a blocker; sensor retrofits cover that ground, as described in our guide to getting production data out of old machines.

What Does PLC Data Collection Typically Cost?

For a single modern PLC already on Ethernet: often just engineering time, typically a few days to map tags, stand up a collector, and validate the data. For a serial-era controller: add a $200 to $700 gateway and somewhat more archaeology. A ten-machine mixed fleet, brought into one broker and database with dashboards, typically lands in the $15,000 to $60,000 range all-in depending on how much archaeology and how much software polish is involved. The recurring costs are where architectures really differ: commercial OPC servers and historians carry annual support fees, while open stacks trade fees for a maintenance responsibility someone must own.

FAQ

Can I collect data from a PLC without changing its program?

Almost always, yes. Reading registers or tags is a passive operation supported by every mainstream controller, and most collection projects never open the program at all. The exception is when the value you want isn't computed anywhere, in which case a small, carefully reviewed program change (or an external sensor) fills the gap.

What's the difference between OPC UA and MQTT?

OPC UA is a full client/server standard for browsing and reading structured, typed industrial data, usually spoken near the machines. MQTT is a minimal publish/subscribe transport that moves whatever payload you give it, usually northbound to brokers and clouds. They're complements, not competitors, and a common architecture reads PLCs via OPC UA or native drivers, then publishes MQTT upstream.

Is it safe to put PLCs on the network for data collection?

It's safe when done deliberately: keep controls on their own network segment, let a dual-homed edge device or firewalled DMZ carry data outward, block inbound writes, and never expose a PLC directly to the internet. Most industrial security incidents trace to flat networks and remote access shortcuts rather than to data collection itself.

Should I buy a Kepware-class OPC server or use open-source collectors?

Scale and staffing decide it. Many protocols, existing SCADA, and a preference for vendor support favor the commercial OPC server; a smaller fleet with software capability in-house favors the open edge stack. Plenty of plants run both, and the good news is that MQTT in the middle makes the choice reversible.

If your PLCs are sitting on data you can't see yet, the path from panel to dashboard is shorter than it looks. Willowark's industrial automation engineers work both sides of that path, controls and software, and can tell you quickly which route fits your fleet. Start the conversation with a list of your controllers; that's genuinely all we need.