10 Years Ago, We Decided to Switch to Beckhoff PLCs. Here's Why.

  • Some introductory notes.
  • Different systems, different outcomes.
  • Two ways.
  • Traditional PLCs.
  • ‘Less’ traditional PLCs.
  • Our criteria.
  • First decision: Tradition vs. Innovation.
  • Second decision: Which PLC manufacturer to pick.
  • Summary.

Some introductory notes

This post is a response to Jakob Sagatowski’s invite for me to share my view on how Beckhoff's TwinCAT3 solution compares to other PLC manufacturers. This text is an amalgam of personal experience, gut feelings, and strong opinions; developed over the years — so please, take it as such.


In this comparison, two main aspects are considered: the overall ecosystem of a given platform, and the programming/software development tools.

Some background: The perspective here is of a programmer working in a company (MTS) that builds single-purpose machines — each original, rarely repeating projects. The company is growing, on average, about 20% every year, and it is difficult to find the right people for the right job. In this environment, the life of a programmer is extremely challenging: the last in the production chain (often finalizing the job in the truck on its way to the customer), yet also the first to be called whatever the problem is; mechanical, electrical, software, etc. Thus, this is a story about the quest to make this life much more meaningful and far more efficient.


Different systems, different outcomes

MTS uses different PLC systems — the mixture of platforms roughly approximates the spectrum of manufacturers currently present in Europe. Here is a list of those that I can recall: Siemens, Scheider (Unity, PL7), B&R, Allen Bradley, Omron, Bosch, and some more exotic systems like Delta, Panasonic, Mitsubishi, and Horner. Lastly, some CoDeSys based platforms from Schneider (SoMachine), Rexroth (IndraLogic), and Beckhoff (TwinCAT).

This variety of systems was bearable until the machines’ software was limited to the control logic and some HMI. It got seriously out of hand when the demands crossed the line into the expanding requirements for extensive data acquisition, data-driven applications, and rich visualization. The explosion of requirements came roughly around the time of the Industry 4.0 initiative, and perhaps more importantly; when people became familiar with smart devices, and fully realized the potential of such technologies.

There was no longer much sense in working with an unlimited number of PLC platforms. It soon became apparent that the only way to be efficient was to select a limited number of systems — ideally one.

The aim was to create well-crafted libraries that would solve the most common programming problems — such as; coordination primitives, and component libraries with a set of scalable, reusable, and testable components. All of this to pave the way to industrial-scale programming, without the necessity of reinventing the wheel (or parts of it) for every single project.

Two ways

It would be a long article to create a side-by-side comparison of all these systems — so, here is a daring categorization into two groups (divided by the underlying philosophy behind the design of these systems):

Traditional PLCs

Traditional manufacturers have a well-implemented FBD, LD, and IL. The running environment is native to the CPU used by the platform. The quality of the implementation of the SFC and the CFC depends on the manufacturer — some are great, others are terrible!

Additionally, the implementation of ST has its issues in all traditional platforms — in some of them it is absolutely shameful!

Traditional manufacturers have an excellent legacy in making robust, durable, and reliable hardware, which is relatively easy to commission. They are also known for their excellent documentation. Into this group belongs Siemens, Allen Bradley, Omron, Mitsubishi, and a few others.


‘Less’ traditional PLCs

Generally, I refer here to the platforms that run on more advanced hardware, often PC-based (Windows/Linux), some variants of virtualized PLC environments, and fully compiled programs. Into this group go a variety of CoDeSys based platforms, such as: Rexroth – IndraLogic, Schneider – SoMachine, Beckhoff – TwinCAT2-3, PhoenixContact – PLCNext, and B&R (a representative of a non-CoDeSys platform).

These systems have traditionally excellent ST implementation. In the case of CoDeSys; LD, FBD, SFC, and CFC were a weak point in the past, but with time they became better. An essential feature of the CoDeSys platform is the implementation of the OOP (Object-oriented Programming) extension, which will be addressed later.

The weak points in this group are poor documentation, limited support, and relatively small communities.


Our criteria

The core question in this categorization is: ‘What tools does the platform offer for programming?’. Additionally, what is the speed of development, the effort needed, and the scalability potential on a given platform? These questions ultimately boil down to the time it takes to reach the market, and the cost of programming/commissioning; both of which will be highly dependent on the tools used.

Another important aspect of this evaluation is the whole ecosystem that a given platform offers. The software needs hardware to run on, and in industrial automation, it is not only the PLCs’ hardware but also the peripheries, I/O, and bus systems. The aspect to consider here is how much time, knowledge, and effort, is needed to commission the hardware.

In other words, we do not focus on how much we pay for the hardware, but rather how much we pay for making that hardware operational, and what is the cost of interconnecting with other systems in the automation pyramid?

First decision: Tradition vs. Innovation

One can get the same result using different tools. For example, the multiplication of two Roman numerals provides us with the same result as an identical operation with two decimal numbers. However, one of them is certainly more comfortable, faster, and less prone to error (no prizes for guessing which one). If you are interested, I have previously written another analogy - my favorite one here.


So, I will make this courageous statement: Structured Text is the only true programming language in PLC systems (it is not perfect, but it is the best we have).

LD, FBD are valid tools, but not precisely the result of software engineering; they are instead a better version of cable wiring and soldering microchips, respectively. In other words; electrical, not software engineering, is the philosophy behind these tools.

Second decision: Which PLC manufacturer to pick

Let us get back to our company story — we found ourselves faced with a decision that would influence the future course of the company: which of the PLC manufacturers should we choose to invest most of our resources in, and to build a framework with?


Our requirements included:

  • Support for Object-Oriented Programming. OOP is a key aspect, even if it is not the only cure for all paradigms. It offers a series of advantages: (a) the ability to describe a physical object (components) in terms of their properties (object properties), and behavior (object methods), (b) effective componentization and reusability — an existing object can be modified with the methods and properties overriding whenever necessary; to adjust the behavior of an object in the consumers’ solution, and (c) it makes a much more declarative approach in programming possible; improving the readability of code by a landslide!

  • A single environment for programming and commissioning without the need to switch constantly between systems (I/O, drives, vision, safety, HMI, eventually higher-level frameworks and languages).

  • A real PLC based on a PC platform. The claim that only hardware-based PLCs are stable, durable, deterministic, and reliable is a false myth! This myth is fed by those who are making a profit from selling a few cents’ worth of hardware (a small CPU, a few MB of memory) for several hundreds of EUR/USD. PC-based systems can have the same qualities and, in fact, in some respects (especially performance-wise) even excel over the hardware-based platforms.

  • Great variety of I/O hardware. As a machine builder, we needed different options to choose from. Not just one product line, but a dozen.

  • Source control. The possibility of using a modern source control system that would give us the power to control, observe, and manage the changes in the code.

To cut a long story short: When we compared all the remaining manufacturers side by side, Beckhoff and its TwinCAT3 was the only one left.

Moreover, this has allowed additional advantages:

  • EtherCAT is an incredibly well-designed and fast bus system (no IP address, means fewer troubles with IT and security)

  • Functional integration with Visual Studio, which is in our opinion best IDE to date, and the integration makes it natural to create solutions with higher-level languages and frameworks.

  • Even bigger variety of I/O hardware. Including ‘scientific automation’ that, in many scenarios, is an extremely fitting replacement for NI LabView, and OCT (One Cable Technology) components (drives, I/Os)

  • Ads. A well-supported and stable communication system infrastructure — it is simply phenomenal when it is used to pass data between PLCs and PC-based applications.

The decision to pick Beckhoff was made almost a decade ago, and we have no regrets whatsoever.

Also, we made this decision when the market share of Beckhoff systems in the area was close to nothing. Since then, we were able to convince most of our customers to switch from other platforms, because we obtained the solutions faster, cheaper, and with tons of features that were simply unachievable with other systems.

There are still some customers that do not accept Beckhoff PLCs, and for these customers we ported some parts of our framework to Siemens’ TIA portal, but we hit a ceiling very soon! With Siemens, you can only get so far, there is no way you can achieve the same results!


Beckhoff's ecosystem is not without imperfections. For instance, integration with other non EtherCAT bus systems can be cumbersome; online changes are often high-risk operations, once your PLC runs into “yellow” state with an obscure page-fault exception you may spend a lot of time guessing where the problem originates (most likely programming error, just very hard to intercept).

Also, the documentation could be much more extensive. Here, I would invite the community of TwinCAT users (myself included) to share and spread any knowledge that may be becoming more active on StackOverflow or some other proven platform, but not only answering, asking as well; there are no stupid questions except for those not asked.

With this said, I fully agree with the list of pros and cons exposed by Jakob Sagatowski — the source code stored in the XML files, and the missing release notes, are especially disgruntling!

Nonetheless, all in all, looking around, Beckhoff is probably the best bet. Our industry needs to evolve, and Beckhoff represents a highly viable path.

Tags: Deep Dive

Peter Kurhajec
CTO of Inxton

Peter Kurhajec

Hello! I'm the CTO of Inxton! More than a decade ago my pet project turned into a full-time job - INXTON. Now I'm on a mission to bring industrial automation and information technologies together.