I have been using TwinCAT for quite some time now, and since I started developing software with TwinCAT it has changed almost everything for me as a software engineer, both as a profession and as a hobby. This includes the programming language, development environment, software development processes, hardware, communication protocols and much more. I have recently philosophized about how my life as a software developer has changed compared prior to doing automation software. Overall, I would say that I can do tremendously more things (in a reasonable amount of time) with TwinCAT by myself, than I could do before when I was developing software in the “standard” programming languages. It has given me opportunities to work with insanely fun projects that I would never have worked with if I didn’t start with PLC software development. What I would want to share with you is a list of five things that I think Beckhoff have done right, and five things that they could improve.

To be fully clear, this list is 100% my personal opinion and is 100% subjective and might not represent the average TwinCAT developers opinions. The list is in order from good to best, and from bad to worst (respectively). Let us start with the bad things.

Five bad things Link to heading

5. Resources Link to heading

Now this one is not per se a bad thing. When I started TwinCAT s/w development, the Beckhoff documentation had lots to wish for, but this has vastly improved over the last years. What I am missing however is more resources than the Beckhoff infosys. If you try to find information on forums, StackOverflow, tutorials, open source projects or blogs, you will have limited success compared to for example doing C++ development. Obviously the TwinCAT (and even PLC) community is considerably smaller than for the “standard” software fields, but I can’t help but feel that the field of automation is much more closed in terms of sharing knowledge. Most likely 99% of the problems people have with TwinCAT goes through the Beckhoff support, and all that knowledge is kept within Beckhoff why I think it would be great to have an alternative resource such as a Beckhoff forum, just like Siemens have.

It should however be noted, it is not a completely dry desert:

4. Licensing for non-Beckhoff hardware Link to heading

In one project I was involved with the environment for the electronics was very tough, and we wanted to have a PLC that was IP67-classed, which Beckhoff didn’t have at that moment in time (there is one released now, at least on paper). We could not use a Beckhoff PLC, but we wanted to run TwinCAT. The decision was taken to try to source the hardware from another supplier that specialized on making hardware for tough requirements but run TwinCAT on it.

Beckhoff’s licensing model for TwinCAT and all the supplements is built on a model based on platform levels. It starts on the platform level of 10 for basic single-core low-performance CPUs, all the way to platform level 94, for 64 core CPUs. The higher the platform level, the higher the cost of the license. The platform level 90 to 94 is for everything that is not Beckhoff hardware. The IP67 PC we found had the exact same CPU as a Beckhoff PLC with performance class 40, but because it was not a Beckhoff PLC, it was classed as performance class 90. If you are at level 90, licenses get really expensive considering we were using a low-power 2 core CPU. Because of the cost of all licenses, it was not possible to motivate us to run TwinCAT.

Now, although TwinCAT is PC-based control it doesn’t mean you can run TwinCAT and expect good performance with low jitter just because you have a computer where you have 200 FPS in Counter-Strike. You cannot expect to have good deterministic performance with EtherCAT just because you have the fanciest Realtek 2.5Gbit NIC. There is a whole science behind this, but there are many users that are aware of this. However, with some careful analysis and adjustment of BIOS-settings on certain platforms it is possible to get equivalent performance. What I guess is most important is the questions of support. It is obvious that you shouldn’t expect Beckhoff to support TwinCAT issues on hardware platforms that are not Beckhoff, why it would be nice to have an option of ordering the equivalent license, but with limited support.

3. Source control Link to heading

TwinCAT uses XML to for storage of all their source code instead of plain text. For someone with an pure automation background this might not matter too much as version control is more an exception than a rule, but for me it makes my life tougher. Doing diffs and automatic merges between branches of code using the standard tools I’m used to unnecessarily difficult. Even if I don’t change anything in a function block, TwinCAT can make some obscure changes to some row in the file just because I opened and saved it.

There are certain things that you can do to minimize the amount of unnecessary changes to TwinCAT source code, like enabling separate line ids (and ignoring the source control of the LineIds.dbg-file), using the “Minimize ID changes in TwinCAT files” and most importantly making sure to use the same version of TwinCAT XAE and settings when developing the software together.

To give Beckhoff some slack, this can be compared to other PLC brands in which some cases all code is stored in binary blobs making it completely impossible to use standard VCS as Git or SVN, and where you then will depend on proprietary solutions (either the manufacturers own solution or third party like Auvesy’s version dog).

2. Software development practices Link to heading

The software development practices in the automation industry are stuck in the ’90s. To be fair, this is not something specific for TwinCAT or Beckhoff, but rather the automation industry. The field of software engineering and the field of automation have vastly different backgrounds and have emerged from two quite different fields which is the most likely reason it is so different today.

While most of the software development world has:

  • Developed good design patterns to make software re-usable and easy to maintain (although it can be discussed whether design patterns are needed in the first place)
  • Developed processes and tools for doing continuous integration/delivery
  • Developed processes and tools for testing software all the way from the lowest level of unit testing, integration testing, system testing and then only as the final point doing acceptance testing

At the same time the field of automation is all about global variables, function blocks with 2000 lines of code, function blocks with ten levels of inheritance, copying of the entire TwinCAT project folder and naming it “Working 2020-06-07 version 2” instead of doing proper version control, only doing tests at the machine etc.

I don’t want to be the guy that only complains about this without doing anything about it, and that’s the reason why I have this blog and that I have created the TwinCAT unit testing framework. I can see more and more of the trends of modern software practices being discussed on LinkedIn and on Reddit/forums for TwinCAT, which I think is a positive trend.

1. No release notes Link to heading

This one has driven me crazy so many times it deserves to be number one. For some reason or another, Beckhoff refuse to have proper release notes when they release new versions of their software. Now why would this be a problem, you might ask? Let’s have an example. I have worked with a team that has developed software controlling a piece of a machine that costs over 1 billion (yes, billion) €. We’ve had some issues with the TF6100 OPC-UA server/client. Talking with the Beckhoff support, you might get information that there will be new release that addresses your issue. When it’s released, you get this information either from the Beckhoff support, or the recent RSS feed that describes any updates of the software they are developing. Beckhoff have recently updated TF6100, and the information available in the feed is:

TC3 OPC UA has been updated to version 4.3.30. The new version is available for download. It includes optimizations for the setup, server, client, gateway and configurator. Please consider updating.

I would gladly consider upgrading if I knew more specifically what was included. What optimizations more specifically? Does it only increase performance, or have some bug fixes been made as well? In that case, which ones? For this particular supplement, I did an upgrade of the TF6100 in the project (because I needed a newer version of the OPC-UA server), but suddenly the OPC-UA client (accessible through PLC function blocks) stopped working. I spent days at debugging, and eventually I concluded that something must have changed with the client. After some talk with the support, I was informed the whole OPC-UA client had been rewritten because of a new SDK. Had I known that there was a new client (or at least that it had changed) in the OPC-UA supplement, it would have saved me much time and frustration. This was just one of many times where I wished I knew what was changed. By not releasing more information, Beckhoff forces me to take uninformed decisions. If I have version of the OPC-UA server currently running, I want to know what changes to it have been made so I can make a more educated decision on whether I should upgrade or not. The release notes do not have to be a PhD either. Just a few sentences and bullet points to let us know what has changed.

(Beckhoff do write release notes, but only for every new build of TwinCAT).

Five good things Link to heading

5. The development environment Link to heading

Beckhoff have chosen Visual Studio (VS) as the development environment for TwinCAT 3 software. For me coming from a “regular” software developer background, this feels much more natural to use as IDE than the proprietary editors of many other PLC brands. It’s quite neat to write .NET/C# code with the same tool as writing real-time critical applications. What Beckhoff have basically done is to take parts of the CODESYS IDE, and integrated it into VS. By default, you can use most of the normal VS versions, but Beckhoff also includes a version of VS with the TwinCAT XAE installer (called the TwinCAT XAE shell). Most of the functionality in VS that you’re already used to still works as usual, although with some limitations. By introducing existing software engineers to a tool that they likely already recognize there is one less obstacle to overcome to become a PLC s/w developer.

4. The trial license Link to heading

I’ve always taken it for granted that the development environment should be free. There are hundreds of IDE’s for Java, C++ and JavaScript, and various of other software to complete my software tool chain, which of most are completely free. As software development is not only my job, but also my biggest hobby it’s a necessity for me to always be able to do some testing and evaluation of the products at work or home to know whether it’s my cup of tea or not without having to cash out. When I started with automation software, I realized that it was different in this field. Without mentioning anyone in particular, there were some that required me to pay thousands of € every year, for a single developer license. With TwinCAT I don’t have to pay a single cent to download the development environment. The full runtime with all various supplements can be downloaded and run for a week at a time. Once a week has passed, you only need to enter a captcha and you can go on for another week. This makes it possible for me to test and evaluate (and even develop the full product) prior to purchasing it. Using virtual machines, I’m able to run various versions of TwinCAT at the same time on the same machine which I’ve had to do at several occasions.

The only things that doesn’t exist as an evaluation license are the development tools (such as static code analysis and the real-time monitor) which can be understandable as developers would probably just re-generate the trial all the time and never buy the licenses.

3. The support Link to heading

As an engineer, it’s easy to talk about the performance, the capacity, the pros/cons of this solution versus that and just generally the numbers but what’s equally important are the humans involved in helping you reaching your goal. Sometimes the resources on the infosys are not enough, and then you have to contact the local Beckhoff support office. At any time I can call or e-mail the local support office and get immediate support/help. I’ve always had first-class support, and they’ve always walked the extra mile to solve my issues. Did I also mention the support is free?

2. The very concept of TwinCAT Link to heading

I was close to put this as number one, it was a close shave. Simply put, I think Beckhoff have gotten the concept of TwinCAT 100% right. Instead of solely relying on a 100% proprietary OS for the PLC to work, they have developed the TwinCAT kernel for all real-time critical software and Windows for everything else. The closest I can describe this combination of TwinCAT and Windows is as Travolta dancing with Karen in Saturday Night Fever, it’s just a perfect combination. It’s not due to the fact that it is Windows, for me it could as well have been any derivative of Linux, it’s more due to the fact that it gives me as a developer the possibility to still use my ordinary software for everything that is not real-time critical. If I want to develop some applications they way I’ve always done it I can still do it. Also, it’s not just about my applications. Because of this solution, we get everything else that we are used to from Windows as a full TCP/IP stack, support for various hardware (scanners, printers, network hard drives), command line tools etc. Another huge advantage of this concept is that you can run the full TwinCAT XAR on your standard computer. This has many use cases, with a few being:

  • If you’re a student/beginner, you can evaluate/learn TwinCAT on your laptop without having to buy any special hardware
  • I often work on-the-go (trains, flights etc) and then I can run most of my software without access to any particular hardware other than my laptop
  • I can use virtualization technology to create tens or even hundreds of PLCs for various purposes

While I was working for the ELT project, I did parts of the TwinCAT software sitting with a beer under a tree in the Englischer garten and testing it out on the spot. If that’s not quality of life, I don’t know what is.

Sure, you won’t get 100% deterministic low-jitter performance, but this is in most cases not necessary. It’s these just type of things you start to take for granted after a couple of years, but which you then realize is such a neat thing once you start to think about it.

Now, I have a PLC both at home and at the office, but this is only convenience/few special use cases and it is not a necessity to run TwinCAT software.

CX5140 home

I look forward to the new release of Beckhoffs derivative of BSD (Tc/BSD) as an alternative to Windows.

1. The possibilities Link to heading

There is so much you can do in this single development environment. Want to write software that reads temperature, pressure, flow and humidity sensors and at the same time do some monitoring and at the same time have a safety feature that powers a system off based on some criteria? While you’re at it, maybe you want to control 25 motors, all synchronized together like a group of birds in the sky together below 50µs with each other? Why not add some fancy HTML5 capable front-end that will feel modern and look good? Want to have quality control on the fly? Add a GigE capable camera and some smart vision algorithms. Further down the chain, there might be people that want to look at the data you’ve gathered to increase the quality or productivity, then you might publish the data to a cloud provider or a local database. There is simply so much I can do, I have so many possibilities on my finger tips when I start an instance of Visual Studio and the TwinCAT XAE. I simply don’t see myself getting bored with TwinCAT software development any time soon.

When I started with TwinCAT I thought I would be able to catch up with all the new stuff that was released and that I would be able to learn everything. Since then I’ve given up on that idea. That was very naive of me, as the flow of functionality that Beckhoff releases with every new release is overwhelming. Nowadays I only focus to learn the new stuff that I find fun, preferably in combination with solving an employer’s problem.

A few final words… Link to heading

Although this is a five bad and five good things, I should mention that it has been much easier to come up with the good things than the bad. If I would write down a complete list of all the bad and good stuff I find with TwinCAT, the ratio between these two would be overwhelmingly in favor for the good. What I’m trying to say here is that everything can always be possible to improve, and TwinCAT and the ecosystem around it could be improved in certain areas. Obviously, there are more things that I don’t like with working with TwinCAT compared to doing for example C++. Let’s take the example with static code analysis. If I want to do static code analysis with C++, I have many different options and I can do an evaluation of which one I should go with. With TwinCAT 3, I only have one (costly) option. At the same time, keeping the options down has made my life easier in other aspects, so I guess there are two sides to the coin. It seems we are in a time where the automation and software industry are meeting, and I’m happy to be part of that journey.

Do you agree with this list? Are there any things that you find Beckhoff have done just perfect, and other things you feel should be improved?