Beckhoff Technology Days 2024 (english)

I had known Beckhoff for a long time, like everyone else I think; however, this was the first time I attended an organized presentation of theirs.

Each product/topic had its own reference technical expert, so it was possible to receive a comprehensive answer to every type of question.

I really liked the calibration of the topics, Beckhoff has an infinite catalog of devices, the risk of getting bored in a sea of technical data sheets was high; they were good at highlighting the salient characteristics of each family without going into details that are forgotten after five minutes and can be found with a few clicks on their site.

The event was aimed at those who do not use Beckhoff frequently, therefore, in addition to the new products, it was also possible to have an overview of the consolidated technologies that characterize it as a hi-tech "content producer" company. And this was a great choice too.

In the end, there was a lot of content presented but it was easy to follow the flow of information.

My compliments to the fire team.

I won't give you information about the product, that's why there is the reference site where you can find everything you need, I prefer to talk to you very briefly about three topics that define and characterize the Beckhoff philosophy: PC Control, TwinCAT and EtherCAT.

PC Control

The concept of PC Control is the cornerstone of Beckhoff, born from an intuition of the founder, Hans Beckhoff, who in the early 1980s hypothesized using a PC as industrial control hardware.

The principle, very innovative for the time, was to separate the hardware layer from the software layer in a PLC, until then seen as a closed and monolithic entity. This allowed the advantage of using all the software present in a normal PC alongside control software, all managed by a real-time layer to guarantee the determinism of the control logic.

Initially, and for many years to come, this concept raised many doubts; I myself have personally seen a system devastated by lightning where the CPU, an S5-115U, was still functional.

It was essentially a technological problem of the time.

However, the principle was a winning one and in fact time has proved Hans Beckhoff right because today this concept has actually won and now I will demonstrate it to you.

A "classic" HardPLC is built around an ASIC chip (*), which is a custom processor whose instruction set is that of that PLC's lowest level language, and has a proprietary micro operating system written internally.

An example of a relatively recent PLC with a dated architecture is represented by the Rockwell Micrologix 1400, equipped with an Altera Cyclone II(*) FPGA; but this stuff is on its way to extinction.

Let's leave the additional software aside for a moment and just focus on today's modern architectures.

Let's look at the Siemens S7-1200 CPU: It's a traditional PLC. The main processor inside, however, is an ARM CORTEX-R4(**) produced by Renesas.

The CX7000 PLC, on the other hand, is a PC Control (because it is produced by Beckhoff) and features an ARM CORTEX-M7 processor.

I don't know the processors installed in Siemens' S7-1500 line, but I'd be willing to bet your dinner that it's CORTEX-R7 or R8; and if one day they announce 8 core CPU, it will most likely be CORTEX-R82.

There is something not right, we have two very different definitions for the same architecture.

The reality is that today creating multicore processors with the advanced features that the market requires is an uneconomical activity, even for the big players. It is simpler, and personally I would add more effective, to rely on those who create these technologies professionally. The same goes for microkernels, there are many ready-made industrial or military-grade systems for ARM and INTEL; you just need to customize them for your peripheral hardware.

These PLCs which, from the perspective of the old millennium, we would define as hybrids, are simply modern PLCs, where the hardware layer is decoupled from the operating system and control software right from the design stage.

Siemens recently streamlined the performance level of its CPUs by adopting standard multicore motherboards for all PLCs. With a software architecture that was most likely already based on ARM it was certainly not an epochal upheaval, in this way efficiency was achieved.

I hope I haven't destabilized you, but today the vast majority of PLCs, at an architectural level, conceptually derive from the "PC Control" family.

(*) If you want to learn how to design a processor using programmable logic (FPGA or ASIC) you can take a look at this article of mine.

(**) If you don't know CORTEX-R and want to know more about redundant and real-time safety systems you can take a look at this other article of mine.

TwinCAT

It is the Beckhoff systems development system.

“TwinCAT is powerful but simple to use”, this is what we were told, and honestly I would not have expected a different statement from a non-independent interlocutor.

At first glance, seeing the demonstration, it seemed true, but I wanted to understand if this was only due to the technician's considerable experience; so when I got home I took the boomer test.

The boomer test involves the installation and first use of software from scratch, without the aid of tutorials, by a non-digital native (precisely the boomer, which would then be me) to verify the intuitiveness of the system.

After the usual registration, I downloaded the package consisting of a single file and installed it on a virtual machine; so far nothing exciting to highlight: everything happens quickly without the need for external interventions.

TwinCAT can be downloaded for free and it is also possible to activate runtime trial licenses which can be renewed with a simple click upon expiry. It is therefore possible to create and test your projects in simulation without spending a single euro before going into production; truly remarkable.

I had some problems starting the runtime, but this only depends on my virtual machine, quite compromised, in which I had reserved some cores for some "borderline" experiments; I am convinced that installation on a normal system presents no problems; in fact, once order was restored, everything went well.

TwinCAT is essentially a mega-plugin for Visual Studio, of which it takes advantage of the entire editor and window management infrastructure, while at the same time supporting specific graphic editors for Ladder and SFC.

This, in my opinion, is a very smart choice, Visual Studio has a UI that boasts years of improvements behind it and is a very fast and robust environment.

The process is however completely automatic, if a recent version (2017-2022) of Visual Studio is already installed on the system, it will be used, otherwise a customized version will be installed (which essentially does not contain the Microsoft compiler).

It is important to highlight, for those who already have Visual Studio like me, that the installed instance is not modified in any way, which I honestly wouldn't have liked, so don't worry. TwinCAT, however, from the user side presents itself as an autonomous and independent program.

The setup of the program is quite "reassuring", all the things we expect are there where they should be. Project explorer on the left, multipage editor in the center, and various property windows on the right.

The subdivision of the project is also very rational and ultimately follows the guidelines of the IEC 61131-3 standard with POU, Task and I/O management separated by context.

In the end, it only took a few minutes to write a small working project, completely from scratch, containing a PLC, a small fieldbus, and the variable graph.

I haven't delved into the management of the axes, but I've seen two motors synchronized with a couple of clicks, so I don't expect too many surprises.

Boomer test passed with flying colors.

A very interesting aspect to highlight is that TwinCAT, in addition to the five canonical IEC languages (IL, LAD, ST, FBD and SFC), allows you to use C++ code to write your own blocks or even incorporate MATLAB/Simulink libraries.

C++ blocks are native, therefore not FB wrappers written in the traditional way. This allows you to insert even more sophisticated processing into your control program without having to bother with an external PC.

Imagine you want to run an FFT or run surface shear optimization algorithms for which you need to solve differential equations. Even the analysis of the slope of a signal, which is conceptually very simple, but involves the analysis of a first derivative function, can be annoying to carry out in ST.

Ultimately TwinCAT is an excellent product, very responsive even on a virtual machine at the limit of survival, like the one I used.

TwinCAT vs ctrlX

I would now like to make a small comparison with a similar system, the Bosch ctrlX.

Apparently the two systems are quite similar, sharing the same basic philosophy of hardware/software isolation, however they combine this concept differently.

In ctrlX the APPs are all completely isolated and communicate with each other via ctrlX Data Layer.

In TwinCAT there are modules, which can be created with various technologies, including MATLAB/Simulink, which by default all reside within the same project and present the standard TcCOM interface. If necessary they can become independent programs and communicate with each other via ADS (the TwinCAT transport layer).

Essentially, in ctrlX the main architecture revolves around APPs, while in the Beckhoff world it is more correct to talk about modules and libraries.

Finally, ctrlX is "dockerized" using snap, Beckhoff doesn't seem to have the same level of isolation at the moment; However, a new architecture based on Hypervisors and virtual machines has been announced (but I know little about it to be able to talk about it).

EtherCAT

EtherCAT stands for Ethernet for Control Automation Technology.

It is an Ethernet-based deterministic fieldbus; it belongs to the protocols that I define as elegant: it is light and efficient. It has not undergone changes over time, the current version is the only one in existence, and can easily scale towards increasingly higher speeds, this demonstrates the robustness of the project.

Its main characteristic, in my opinion, is the efficiency in the use of communication resources: the data is processed by the nodes along the path, without the need to interrupt the communication flow, inserting or withdrawing I/O information on the fly.

A distributed clock mechanism is used for synchronization, which leads to very low jitter, significantly less than 1 μs. As a result, EtherCAT does not require special hardware in the master device and can be implemented via software on any standard Ethernet MAC, even without a dedicated communications coprocessor.

EtherCAT is transported directly within the standard IEEE 802.3 Ethernet frame, so it is easily handled by the many protocol converters available on the market. Furthermore, again thanks to its simplicity, it can be easily encapsulated in higher level protocols (obviously losing the timing but still preserving the payload).

The EtherCAT specification is public and its implementation is royalty-free, you can find open source EtherCAT stacks widely used by different manufacturers online; Custom chips that encapsulate EtherCAT have also been developed, but there is no contractual obligation to use them.

Finally, the secure profile (FSoE) also exists for EtherCAT.

Conclusions

Beckhoff is a proactive company.

The OT market is less dynamic than the IT market; there are the big players who, thanks to their market shares, impose their closed, almost dogmatic solutions, to be accepted on faith; then there are smaller companies that propose open and documented technologies, leaving the task of natural selection to the market, in pure Darwinian spirit.

As a member of the Free Software Foundation (and a non-believer at that) I prefer the latter, but obviously I take it as a personal opinion.

The only certainty is that the quality of the technological solutions proposed is not always directly proportional to market shares.