Ten PLC Protocols, Seven Vendors: How You Ask Beats What You Use

The Siemens article and the Beckhoff article each stayed inside one vendor, which kept them fair. Every row shared a controller, so a difference between rows was a difference between protocols.

This article crosses that line on purpose. Doing so takes care. An S7-1212C and a CompactLogix are different machines. Put an S7Comm figure from one next to a CIP figure from the other and you are comparing two computers, not two protocols.

But nobody picks a protocol in the abstract. A plant engineer has a controller that is already installed and a job to do: get these 2500 values into the historian twice a second. What that job costs on the controller in front of them is a fair question. For them it is the one that matters.

So this article compares three things, each in the way the data allows:

Two kinds of run, both reading only.

A byte sweep. Nine tags that every protocol on the bench can express: whole scalars and whole arrays of BOOL, INT, DINT, REAL and STRING. Each target read every tag in its own request, then all nine together in one request, a hundred times. Bytes were counted inside the driver, at the transport, including the protocol’s envelope. Nine drivers took part, on eleven controllers.

Load runs. The same ladder on five of the seven vendors, Siemens, Beckhoff, Schneider Electric, Rockwell and Mitsubishi: 80, 500 or 2500 integers, read at a held rate from once every 2 s to every 10 ms, for 10 s each against an idle baseline, three passes in rotated order, with the drivers exactly as they ship. A positive control proved each controller’s figures could move before a quiet row was read as "no cost".

One of each, apart from the Siemens CPUs. No figure here is a statement about a product family.

Bytes are the one column that travels. Modbus TCP ran on four different Siemens CPUs in the sweep, with the same register map, and every byte figure came out identical on all four, while the time for the same work differed 3.3-fold. Two sweeps twelve days apart, with several driver releases in between, reproduced the bytes of S7Comm, Modbus TCP, OPC UA, UMAS and CIP exactly.

So a byte figure is a property of the protocol and of how the client asks. The controller that answered makes no difference.

🔒 marks the ways in that were measured with the channel encrypted and the client authenticated: Secure ADS, OPC UA with Sign and encrypt, S7CommPlus and the two interfaces over HTTPS. Everything else ran in the clear. In the tables, indented rows are the unindented row above them with security added.

*S7CommPlus comes in several versions. The older ones can run without any protection. Only the newest is fully secured, with the client authenticated and the channel encrypted. Our driver implements only that version, so every S7CommPlus figure in this article was measured with full security.

Five things stand out.

The spread is thirtyfold. The cheapest protocol moves under 15 bytes per value, the dearest over 450. Everything binary sits between 15 and 60. The two protocols built on HTTPS and JSON are in a different class.

How the client asks shows up here too. Modbus cannot name nine scattered values in one request. Asked plainly it needs 5.7 exchanges per read. Batched by the client it needs 3.4. UMAS, carried over Modbus TCP, names all nine and fetches them in one, and comes out 35% cheaper per value than plain Modbus. Batched S7CommPlus reads the same nine values about 30% lighter than plain. The effect grows with the read, as the next table shows.

Modern is not lighter, unless the client makes it so. On the same Siemens CPUs, plain S7CommPlus moves roughly twice the bytes per value of classic S7Comm. OPC UA and CIP land in the same band. What they buy is symbolic names, types and, for most of them, security. A lighter wire is not among them. Batched S7CommPlus is the exception: on large contiguous reads it costs what classic S7Comm does (see Large reads below).

OPC UA servers differ, too. The same nine values cost 49 bytes each from the SIMATIC servers and 79 from the WAGO’s CODESYS server. The protocol is the same; the server decides how much it sends.

Security costs bytes, not many. Secure ADS adds 12 to 17 bytes per value over ADS without it, OPC UA’s Sign and encrypt about 9 to 10. What grows is the fixed part of each request.

Three caveats travel with the table. The ctrlX figures count the application’s bytes only. Measured separately at the network, HTTP headers and TLS add about 680 bytes per request, which puts its nine values near 1,940 bytes. ADS resolves each name on its first read, so its single-value request carries that lookup and comes out heavier than the nine-value one. And "per value" is only comparable at a stated count. Divide by nine and the fixed envelope of each request is still in the figure. At larger reads the cheap binary protocols drop much further per value than the table shows.

Now the two questions that depend on the controller: how long does a read take, and what does it cost the machine? Two jobs, each run on every controller that offers a way to do it.

First, what "cost" means on each family, because no two measure it the same way:

Rows with the protocol’s plain name show what the protocol does on its own, which is what an ordinary client sends. Plain Modbus TCP, MC protocol and CIP send one request per value. Plain S7Comm sends one item per value, several items to a request, and plain S7CommPlus names every value as an item of its own. Plain ADS takes a handle for every value and releases it after the read, Beckhoff’s documented basic pattern. Plain UMAS names every variable.

Every other row is ToddySoft Connect’s addition to the same protocol. Batched combines neighboring values into range requests: S7Comm, Modbus TCP, the MC protocol, ADS by address, and S7CommPlus where the data block has standard (non-optimized) access. CIP, range read reads the array as one range; CIP, batched packs element reads into shared messages. ADS, by name lets the runtime resolve every name on every read. UMAS, by address reads located variables by their address.

A read that takes longer than the interval cannot keep up. The client sends one read at a time, so that job simply runs slower than asked. The Keeps up column says which.

Check how your client asks before you blame the protocol or the controller. On every vendor here, the gap between asking well and asking badly was larger than the gap between protocols. Read a range, not a list of elements. Let the client combine neighbors. Resolve names once, not on every read.

Size the job before you pick the protocol. A dashboard of 80 values is easy for almost anything on this bench. A historian of 2500 values twice a second rules out several protocols on some CPUs outright, for reasons that have nothing to do with speed: node limits and refused reads.

Look at the wire when the network is shared. Between the cheapest and the dearest protocol there is a factor of thirty in bytes per value. Across hundreds of devices on one segment that is the difference between noise and a planning problem.

Know the setting that splits time between program and clients. Every family here has one, under a different name. The setting decides whether a busy client slows the machine or simply waits. Each controller carries its own.

Measure your oldest controller, not your newest. On current hardware most jobs cost the program next to nothing. On the one old CPU here, every protocol had a limit, and the heavier ones reached it first.

A disclosure, as in the other two articles. I work on ToddySoft Connect, which provides drivers for every protocol in this article, and every number came out of its test suite. Having all ten in one library is also why they could be measured with the same client software. You should know about my interest before you weigh my conclusions.

Three published conclusions from this work were wrong. Each was caught by someone asking an obvious question of a number that looked fine.

"UMAS is the most economical protocol on the bench." UMAS and Modbus had never been compared. They sat in different tables, with different tags on different controllers. Put side by side on nine scattered values, UMAS was cheaper, because it fetches in one exchange what Modbus needs several for. Read side by side on one controller over one contiguous block, the two were equal in time and in cost to the controller. Both results hold. They answer different questions.

"Bytes per value mean the same thing at any read size." They do not. Dividing by the count removes what grows with the values, not the fixed envelope of each request. Between 25 values and 9, batched Modbus nearly doubled per value, while plain Modbus did not move at all.

"OPC UA is an order of magnitude slower." On TwinCAT and on the Siemens G2 that was mostly the shape of the data. Array elements addressed one by one are OPC UA’s slow path. Read as separate variables, the same servers were up to ten times faster. On the S7-1511 the server stayed slow either way.

There is no fastest protocol. There is a controller that is already installed, a job it has to do, and a client that asks for the data well or badly.

Across ten protocols and seven vendors, the client’s habits moved the cost more often than the choice of protocol did. So before the next protocol debate, look at how your client asks. Of every fix on this bench it is the cheapest. On most controllers it is the only one you need.