What is a PLC? How It Works, How It Is Programmed and How to Get Data Out

Three designs are common, and the choice has consequences for connectivity.

For connectivity, the design matters less than which communication modules are installed. A modular PLC from the nineties with a retrofitted communication module may well speak Ethernet, which makes it easier to connect than a compact PLC ten years newer that simply has no slot for one. When assessing a fleet of machines, it therefore pays to look inside the racks first and at the nameplate second. This is especially true where plants have been extended over the years rather than replaced.

None, apart from the language: SPS is the German abbreviation for speicherprogrammierbare Steuerung, a name that set it apart from the earlier hard-wired controllers, in which the logic lived in the wiring. It is the term you meet in German documentation and at German suppliers, and it is also the name of an international automation trade fair, SPS – Smart Production Solutions, held in Nuremberg every November.

In Germany, SPS is searched around 14,800 times a month and PLC 5,400 times; in the US, PLC comes to around 40,500 searches a month (Google monthly average, collected in September 2026). The German figure for SPS does not separate searches for the controller from searches for the trade fair.

The current edition of the IEC 61131-3 standard (IEC 61131-3:2025) describes three programming languages: Ladder Diagram (LD), which looks like an electrical circuit diagram, Function Block Diagram (FBD) with graphical blocks, and Structured Text (ST), which resembles a high-level programming language. Sequential Function Chart (SFC) structures a program into steps and transitions. The former Instruction List (IL) is no longer part of the standard, but it still runs in many existing plants.

For connectivity, the language matters less than addressing. At Siemens, addressing changed fundamentally with the S7-1200 and S7-1500; more on that below.

In the automation pyramid, the PLC sits at the control level. Below it is the field level with sensors and actuators; above it, the supervisory level with HMI and SCADA. ISA-95 counts differently and places controllers at Level 2, above Level 1 with sensors, actuators and valves.

This hierarchy describes responsibilities; it no longer describes data paths. An ERP system can talk to the supervisory level and also directly to the controller, when the order status is needed as of now rather than as of last night.

More on the levels: What is ISA-95?

Which route is open depends on the generation of the controller, the model and the communication interface that is installed and enabled. This shows most clearly at Siemens, where addressing changed with the S7-1200 and S7-1500. The table therefore shows the Siemens generations. Whether controllers from other vendors have OPC UA, built in or via an add-on module, and which driver connects to them, is shown in the overview further down under “The translator: from PLC protocol to OPC UA”.

Why the S7-1500 has its own OPC UA server

The reason lies in addressing, and it explains the break between generations.

On the S7-300 and S7-400, variables sat at fixed memory locations in data blocks and memory bits. An external system could read these addresses directly because they did not move. The RFC1006 method is built on that.

The S7-1200 and S7-1500 brought symbolic addressing. Programmers no longer have to place their variables at fixed memory locations, and in optimized data blocks the variables no longer sit at a predictable position at all. For programming, that is progress. For external access, it is a break: the address you wanted to read no longer exists in that form.

The built-in OPC UA server solves this by exposing the symbolic names to the outside. Instead of “data block 12, word 4”, you read Line3.Oven.Temperature. A change to the program then no longer breaks the connection unnoticed.

Two things to check: the controller’s OPC UA server requires a runtime license, and it has to be enabled in the device configuration. Without a check beforehand, both only surface in the middle of the project.

An OPC server in front of the controllers, used instead of the built-in server, gives you a uniform symbolic view of every controller it has a driver for, including older ones. On controllers with fixed addresses, such as the S7-300 and S7-400, the names do not come from the controller; they are created in the OPC server. For this case, OPC servers offer dedicated Siemens driver suites.

The S7-1200 and S7-1500 can also be addressed through the classic S7 protocol; an OPC server lists them in its Siemens Ethernet driver for that purpose. The same applies as with the S7-300: fixed addresses are read. Optimized data blocks cannot be reached this way, so the values have to sit in a non-optimized block. In addition, according to Siemens, “Permit access with PUT/GET communication from remote partner” must be enabled under Protection & Security in the CPU properties; otherwise the controller rejects read and write requests. According to its manual, the Kepware Siemens TCP/IP Ethernet driver also requires the protection level “Full access (no protection)”, because it does not support passwords.

The translator: from PLC protocol to OPC UA

Every controller speaks its vendor’s protocol, such as the S7 protocol, Modbus or EtherNet/IP. An OPC server translates it into OPC UA: downward, it talks to each controller in that controller’s protocol; upward, it exposes all values in one uniform OPC UA view. Behind it, the OPC Router can take over as an OPC UA client and pass the values on to ERP, MES or a database.

Across vendors, this is what Kepware Server (KEPServerEX up to version 6.18) does, with more than 150 drivers for over 300 protocols. Kepware Edge is the container version for Linux, which can be rolled out in a standardized way and managed centrally.

Whether translation is needed depends on the controller. Some have an OPC UA server built in, others get one through an add-on module, and for the rest an OPC server does the translating. The table shows this for the controller families of the four large vendors: according to Interact Analysis (2019 report), Siemens, Rockwell Automation, Mitsubishi Electric and Schneider Electric together account for nearly three-quarters of the global PLC market (74.3%). Modbus in its variants and controllers with a CODESYS runtime, with WAGO as the example, complete the table. The information comes from the vendors’ data sheets and manuals.

“Built in” means that the server runs in the controller itself, in the CPU of a modular PLC. Where it runs on a separate module next to the CPU, the table says “via add-on module”. “Not listed” means that the vendor documents consulted do not list an OPC UA server or a driver. Where the Requirement column shows no license, that does not mean none is needed. Modbus is a protocol, not a controller: the Modbus Organization’s specifications define no mapping to OPC UA, and whether a device also has an OPC UA server depends on the device.

The manual for the Siemens S7 Plus Ethernet driver (version 1.052, from 2026) lists supported firmware up to 4.6 for the S7-1200 and up to 3.0.x for the S7-1500. Later firmware, such as V4.7 on the S7-1200 or V3.1 through V4.1 on the S7-1500, is not listed there.

“Built in” does not mean unlimited: for the S7-1200 with firmware V4.5 through V4.7 and for the S7-1200 G2, Siemens specifies a maximum of 10 sessions and 1,000 monitored items, the 1,000 given in the data sheets as a recommended maximum.

What if the controller is older than the requirement?

The translation layer from the previous section covers this case, and it has a second benefit: when a controller is replaced, that layer changes, and the ERP system behind it stays untouched. A case with a switch from S5 to S7 is described below under “What does this look like in real plants?”.

The protocols fall into two groups.

Fieldbus protocols connect the controller with its devices, for example PROFINET, PROFIBUS, EtherCAT and Modbus. They are designed for short distances and fixed cycle times.

Connectivity protocols link the controller to IT, for example OPC UA and MQTT; proprietary ones such as the S7 protocol over RFC1006, which newer Siemens controllers still speak as well; and in some cases direct database access. OPC UA and MQTT are designed for structure and security rather than short cycle times.

Where the controller and the IT system have no protocol in common, a translator sits between them, described above under “The translator: from PLC protocol to OPC UA”.

More on this: What is OPC UA? · What is MQTT?

A PLC works through its scan cycle and answers requests from outside within the share that communication gets. Its scan keeps running between the individual telegrams of a read request. The main consequence is that several values read together do not necessarily come from the same scan, even when everything is set up correctly. Planning questions add to this: how the interface is laid out, and how often each value is read.

Individual values arrive without context

There is no transaction boundary between the PLC and the system reading from it. A read request covering several values is split into one or more TCP telegrams. The controller answers each from whatever its memory holds at that moment. Between two telegrams, its scan cycle keeps running, possibly several times.

The result: the values may not all come from the same scan. The order number may come from scan 4711 and the matching quantity from scan 4713. With classic access routes such as RFC1006, nothing in the protocol stops this, and nothing flags it. The record looks complete but is internally inconsistent.

Reading ten values is therefore not the same as reading one record.

The error only occurs when a value changes between two telegrams, so not on every read request.

What helps. The fix has two halves, and the first lies in the controller. At a defined point in its cycle, the PLC copies the values that belong together into a separate data area, a kind of snapshot. Only then does it signal that the data may be read. That logic lives in the PLC program, and no tool on the IT side can replace it: only the controller program defines the point in the cycle at which the values are consistent with each other.

The second half lies on the IT side: the OPC Router reads the data area only after this signal and acknowledges once the transfer has succeeded, as described below under “How do you get consistent data from a PLC?”.

The effort is thus split between both sides. In the controller, it includes a data area that stays unchanged until the acknowledgment, setting the trigger and, with a Bit Trigger, resetting it after the response, plus a timeout that resends when no response arrives and reports an error after several failed attempts. In the OPC Router, it is configuration rather than programming.

Poorly laid-out interfaces create network load for nothing

Not every protocol between a PLC and an OPC server supports notifications. Where there is no subscription, polling is the only option: the server asks at fixed intervals, even when nothing has changed since the last request.

That is manageable as long as the interface is laid out contiguously. If the required values sit in one continuous data area, a single request fetches them all at once.

If they are scattered, one request becomes a dozen. Each one costs a telegram, a response and a share of the controller’s communication time. The result is long network cycles for a handful of values.

The layout of the interface is therefore a performance question. The data area is best defined together with the PLC programmer before the first connection is configured. Changing it later is expensive because both sides have to be touched.

The layout makes the biggest difference: contiguous areas instead of scattered individual addresses reduce the number of requests. That is work in the controller.

Then there is the method: where the protocol supports subscriptions, as OPC UA does, the controller reports changes itself instead of being asked. The S7-1200 and S7-1500 can do this through their built-in OPC UA server. Older controllers still have to be polled. An upstream OPC server only moves the polling to a single place, as the next paragraph explains.

Finally, bundling through an upstream data broker, described below under “The PLC runs the machine. Communication gets its share”. It reduces the load on the controller even when the protocol underneath has no subscriptions and polling continues, because only the broker polls the values that the consumers have subscribed to there.

The PLC runs the machine. Communication gets its share

A PLC’s main job is the machine. Its real-time requirement applies to the scan cycle: read inputs, run the program, set outputs, and do it reliably within a fixed time. Communication gets a limited share of that time.

The controller determines how large that share is. Depending on the vendor and model, the share is configurable, or a separate processor handles communication. On Siemens S7-1500 controllers, for example, the share is a CPU parameter, and according to Siemens, organization blocks with a higher priority interrupt communication. Whatever part of its share communication does not use is available to the user program. If the share is used in full, the cyclic part of the program takes longer, up to twice as long at a share of 50 percent. According to Siemens, the default depends on the CPU type and version. A smaller share reduces that extension. Siemens’s function manual “Cycle and response times” (edition 11/2024) recommends factoring the communication load into the maximum cycle time.

Polling density is therefore a planning parameter, and it is set on both sides: in the controller through the communication share and the cycle time, and on the connection side through how often and in what way values are read. This dictates the order of work: first determine which values are needed and at what rate, then design the connection around them.

The load drops when fewer systems ask and when they ask less often, wherever the value allows it. If a database, a dashboard and an MES need the same values, the controller does not have to deliver them three times. An upstream data broker, such as an OPC server or middleware, reads subscribed values once and serves all three consumers from the same request. Individual reads and writes from a consumer, on the other hand, can still go through to the controller: according to its manual, the Kepware Siemens S7 Plus Ethernet driver, for example, can be set not to poll subscribed values faster than a configured rate, but it processes individual reads and writes as soon as possible, regardless of that setting. One decision stays with the plant, and no software can make it: how often each value is actually needed. A temperature that changes every two minutes does not need to be read every second.

The remedy for values from different scans is a handshake: the controller signals that a record is complete and receives an acknowledgment. For several values that belong together, the OPC Router provides two triggers: the Bit Trigger for individual events and the Message Trigger for sequences of records in which a gap should be noticed. With both, the OPC Router waits one more read cycle after the trigger fires before it reads the record, so that the PLC has had time to write all values.

The Bit Trigger is a data point the PLC sets once the values have been completely written. Only then does the OPC Router read them. The manual requires the Bit Trigger to be used with a response bit at all times and gives this reason: if the trigger data point in the PLC changes twice within one read cycle, the OPC Router does not detect the second change. The associated transfer does not take place, and neither does the response bit. If the PLC waits for the response with a timeout, it detects the failure and can send again.

The Message Trigger is, according to the manual, the more reliable of the two, because it uses a counter instead of a bit, the telegram number: the PLC increments it by 1 whenever a new record is ready, and the OPC Router can respond through a data point of its own. If the counter value is logged along with the data, you can trace later whether records were missed or transferred twice, for example when the counter jumps from 5 to 7 or the same counter value is logged twice. That serves traceability and diagnostics. Avoiding a gap is the PLC’s job: it writes the next record only after the response, and resends if no response arrives within a timeout.

The order of steps in the PLC is always the same: write all the values that belong together first, then set the trigger. The OPC Router’s extra read cycle does not replace this: if the trigger is set first, the reader can still pick up an intermediate state.

This is a typical case for the Message Trigger.

The controller writes the values that belong together into the designated data points, such as material number, order number, quantity produced, quantity consumed and timestamp. Only then does it increment the message counter. The OPC Router detects the new counter value, reads the complete record and passes it to the ERP system. It then reports back to the PLC through the response data point that the confirmation has been handed over.

A label specialist, according to its user story on opc-router.com (undated; the company figures in it are from 2017), linked 14 machines to SAP through the OPC Router, with around 15,000 data telegrams a day and posting times below 15 milliseconds. SAP sent formulations and production speeds to the machines, and the machines reported flawed areas back. According to the story, the link to SAP ran over RFC with a handshake.

The return channel, writing orders to a PLC, is technically the same as reading, but organizationally it is something else: who is allowed to write, what happens in a conflict, and what the plant does when the connection is down. These questions belong in commissioning.

A manufacturer of outdoor power equipment, according to a user story on opc-router.com (published in German in 2019), tested motor units in up to nine parallel test cells at the end of an assembly line, with test sequences lasting up to five minutes. The plant used Siemens Simatic PLCs, Sinumerik CNC, Simotion and robots. The story names 16 installations in Germany, plus the plants in the USA and China, with one OPC Router per assembly line and its own local database server. Here a connection was designed once and replicated as a pattern.

A bicycle manufacturer, according to its user story on opc-router.com (undated), first connected the Siemens S5 controller of its electric overhead conveyor to the OPC Router via an IBH interface. About a year later it switched to a Siemens S7 controller and took the changeover as an opportunity to restructure its data transfers.

An automotive supplier, according to its user story on opc-router.com (undated), manufactured car flooring systems for just-in-time and just-in-sequence delivery, with a wide range of variants and complete traceability. There, the PLCs of all stations were connected through one OPC server, and the OPC Router handled communication with SAP.

A container terminal group, according to its user story on opc-router.com (undated), connected handling equipment and facilities, that is, large mobile equipment rather than stationary machines.

A packaging manufacturer, according to a German-language user story from 2020 on kepware-opcserver.de, connected around 500 machines from different vendors in eleven plants, including injection molding machines, with Kepware servers in the plants and the OPC Router installed centrally.

More examples, sorted by industry, are collected in the international use cases on opc-router.com (page dated August 2026).

The benchmarks in the OPC Router manual give some reference points for the path from the OPC server to the target system:

The measurements were taken with an older version of the OPC Router against simulated OPC servers, not against controllers, and the targets were MQTT and InfluxDB. The figures mark the limit of each test setup: at 21,200 data points per second, some values were already being lost, and at 28,500 the OPC server was the limiting factor. What a specific plant can handle depends on the controller, the network and how many values are really needed, among other things. Load also comes from a read interval that is too short for values that rarely change.