Building a Faster
Virtual PLC
A virtual PLC has to leave room for I/O, live values, diagnostics, and logging on top of the control logic itself. That starts with an efficient engine.
We ran Control Seat against the official CODESYS Control for Linux ARM64 runtime on the same OnLogic FR202, both executing compiled IEC workloads on the same processor.
Control Seat was faster on nine of the ten workloads. It led Boolean logic, integer math at 100 operations, floating-point math, timers, counters, and both PI-style control-loop tests. CODESYS led the 1,000-operation integer chain by a narrow margin.
Control Seat led 9 of 10 workloads
Both compiled engines ran on the same OnLogic FR202. Lower execution time is faster.
| Workload | Control Seat | CODESYS | Winner |
|---|---|---|---|
| Boolean logic · 100 | 122.2 | 463.0 | Control Seat 3.8× |
| Boolean logic · 1,000 | 1,215.0 | 4,364.5 | Control Seat 3.6× |
| Integer math · 100 | 402.2 | 3,149.0 | Control Seat 7.8× |
| Integer math · 1,000 | 17,992.1 | 16,838.0 | CODESYS 1.1× |
| Floating point · 100 | 599.6 | 1,931.5 | Control Seat 3.2× |
| Floating point · 1,000 | 5,362.3 | 13,273.5 | Control Seat 2.5× |
| Timers · 50 | 132.6 | 7,963.5 | Control Seat 60.0× |
| Counters · 50 | 132.8 | 1,631.0 | Control Seat 12.3× |
| Control loops · 10 | 87.5 | 510.0 | Control Seat 5.8× |
| Control loops · 100 | 877.4 | 4,640.0 | Control Seat 5.3× |
Official CODESYS Control for Linux ARM64 SL 4.21.0.0 and the Control Seat native compiled engine, measured on the same FR202. This compares IEC program execution, not I/O latency, scheduler jitter, motion, or safety certification.
The timer row repeatedly starts and resets timer blocks; it does not measure a real elapsed delay. Treat its 60× result as a specialized workload, not an expected production speedup. Across the other eight workloads, Control Seat's geometric-mean lead was 3.5×.
The control-loop result matters most
Timers produced the largest ratio, but the control-loop tests are the useful ones. They combine arithmetic, comparisons, limits, and state updates: the shape of real process control.
Control Seat ran the 100-loop workload 5.3× faster and the 10-loop workload 5.8× faster. That is not a promise that your program will run five times faster. It shows the engine holds up when common control operations are combined into one repeating scan.
Predictable floating-point math
Control Seat uses the same defined rounding steps on every supported target. That avoids processor-specific shortcuts that can make the same calculation land on slightly different values on different machines.
Control Seat led both floating-point tests without that shortcut, at 3.2× and 2.5×.
What the timer row actually measures
Timers produced the largest ratio, 60×, and it needs context before you use it.
The timer input toggles every scan, so no instance ever reaches its 100 ms preset and both engines run only the start and reset paths. The row compares function-block call overhead, not on-delay timing.
The timer row measures the cost of calling and updating timer blocks, not the accuracy of a real 100 ms delay. Excluding both timer and counter rows, Control Seat's geometric-mean lead across the other eight workloads is 3.5×. Read 60× as a specialized test result, not an expected production speedup.
Where CODESYS won
CODESYS took the 1,000-operation integer workload by 1.07×. On long unbroken chains of integer arithmetic the two engines are effectively tied.
This row is also the noisiest in the set: the CODESYS p99 is about 1.9× its own median, so a single run can land on either side. If your programs are dominated by long integer chains, treat the engines as equivalent here.
What we measured
Each engine ran on the same FR202 with the other stopped, across Boolean logic, integer and floating-point math, timers, counters, and PI-style control loops. Every table figure is a median from repeated on-device measurements; lower is faster.
Every figure is a median from repeated on-device measurements. The downloadable test kit includes the complete method and sample counts for readers who want to inspect or repeat the comparison.
This measures compiled IEC program execution, not physical I/O or complete-system timing. An engine benchmark is not a controller claim.
Reproduce the comparison
The reproduction kit contains the test definitions, the CODESYS project builder, the environment and result receipt, checksums, and an offline sample summarizer (checksum).
It lets another engineer rebuild all ten CODESYS cases and compare a new run with ours. It requires the official CODESYS Development System and Linux ARM64 runtime.
Why the result is useful
A PLC repeats the same program on a fixed cycle. Logic that finishes earlier leaves headroom for communication, monitoring, and recovery, and lets one industrial computer carry larger programs or more controllers.
Speed is one part of a production PLC. Reliable I/O, predictable scheduling, secure updates, fault recovery, and long-duration stability matter just as much, and each is documented separately with its gaps stated. This result establishes the engine underneath them.
Evaluating software-defined control, or want to test it on your own hardware? Get in touch.
Jack & Warren