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
Resources
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, Stack Overflow, 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:
- The TwinCAT Forum on LinkedIn (not best platform for a forum though)
- PlcTalk (mostly American brands, not so much Beckhoff. Web page looks like it was made by a 15 year old in the mid-90s)
- TwinCAT tag on Stack Overflow
- And some other resources
Licensing for non-Beckhoff hardware
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.
Beckhoffs 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.
Source control
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).
Software development practices
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.
No release notes
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
The development environment
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.
The trial license
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.
The support
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?
The very concept of TwinCAT
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.
I look forward to the new release of Beckhoffs derivative of BSD (Tc/BSD) as an alternative to Windows.
The possibilities
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…
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? Please comment below!
Hi Jakob,
I completely agree with your list! Both the good and the bad. Very good that you also included the positive points. Those are usually the hardest to come up with, because you don’t notice them.
When I entered the automation field, I was also surprised by a lot of things. One thing that stood out is beautifully exemplified by the PLC talk forum: it often feels like automation development is 15+ years behind regular software development. I talked about this with a colleague, who has been in this field longer, and he provided some historical context. That helped a lot to understand the current state of the field.
I also have a story regarding the lack of change logs. Now mine is not as costly as yours, but still :p. There was once a bug in the TF2000 HMI, where the HMI wrote values into the plc when the page refreshed I think. We had some process aborts, each costing 50-100k. Anyway, it took us some time to figure out what was going on. After great support from the Beckhoff, we found out the reason. At was a bug in the HMI which had been fixed in a newer version. If only there were change logs, we might have caused this much earlier.
The Beckhoff support is great indeed. However, also from their side I don’t understand that everything is kept so closed. They must often get similar questions. Why not open source the questions and answers, so the support can focus on the difficult ones? Finally I also sometimes feel it as a barrier to contact support, especially if it feels like a small thing.
Hopefully Beckhoff makes a similar change like Microsoft in the 2010s (https://en.wikipedia.org/wiki/Microsoft_and_open_source) and starts to embrace open source and open communication with the community.
Roald.
Hi
I saw your post on LinkedIn on TwinCAT. I can understand the struggling you experience in a closed system. Therefore perhaps it is useful to look further than the technology Beckhoff provides. Please take a look at https://www.plcnext-community.net/en/ and experience what a really open system can mean for you. All the negative issues you mentioned could be positive if you use the PLCnext technology of Phoenix Contact. Please feel free to take a peak on the mentioned website.
PLCnext is Linux based where C++ code can run directly next to IEC code and correctly synchronized. All without the use of cross compiling. PLCnext provides a deterministic and open automation framework where the user can decide what function extension is usefull. The closeness of the most plc brands are one of the main reasons for Phoenix Contact to develop the mist open automation system.
Great article and I agree on every point made!
Oh the Source Control issues with the XML and randomly changing GUIDs are very annoying. It just seems as though there is so much generated content when we compile that should be saved as separate files, but are just chunked together.
The line numbers are one. I asked Beckhoff about it earlier as it seemed as they didn’t generate all the time. Their response was that the line ids are needed to map the breakpoints to the specific line in source code. They only get regenerated if the “object” is changed (I assume they mean if the file/the method is changed). I have experienced strange behaviour with breakpoints not showing up where I expect them (especially because I use Git with a team of 6 developers and so the line number WILL get jumbled up). Therefore I have left this feature off. It would be good if Beckhoff were to give the option to both separate the line ids, AND regenerate all of them on each compile with a checkbox or something.
Another file where this happens is an .xti file in the _config/Plc folder that contains a bunch of comments linked with guids (which of course continuously change), as well as a list of the memory mappings/variable links. The mapping information should be saved in a separate file to these ‘comment’ sections as well.
In general, anything that is generated should be in a separate file that can be ignored by our source control, and ignoring it should not have any averse affects to our development experience. Hopefully we get some of these cleaned up in a future update.
(as of build 4024.7)
I mostly agree with your list but in my opinion The trial license is a negative thing. There should be no licenses at all when already buying the hardware
Another point is stability, in my experience this is rather poor
I was used to a different PLC brand (Sigmatek) that didn’t require any license at all
My one experience with TwinCat in 2018 led me to the conclusion that it’s OK for a small stand-alone system, but completely unacceptable for large networked mission critical applications. TwinCats version of online programming, “logging on with changes” stopped the PLC almost 1/2 of the time. That doesn’t cut it reliability-wise. It’s not a PLC, it’s embedded Windows 10. It will never be as reliable as an AB or Siemens PLC. Also, try integrating a Cognex camera or Fanuc robot compared with Rockwell, it’s not even close.
I do like the Structured Text editor.
YMMV
Hi, thanks for your feedback. Sorry that your one experience was so bad, I think you should give it a second and third time. I’ve been involved in large “networked mission critical application” (hundreds of PLCs), only relying on Beckhoff, without problems. We’ve had systems where we had to run cycle-times in the PLC and on the fieldbus of less than 100us. Very few can do this. The PC-based advantage is really good. Online editor works fine as long as you are careful and know what you are doing (you can for example allocate more memory upfront for online changes to minimize the risk for problems). Also had system running for years without a single hickup. Windows is only used for non-RT stuff, all RT-stuff is executed in the TwinCAT kernel. ps. I’m not working at Beckhoff 🙂 ds.
Hi Jakob,
first of all respect and gratulations for your blog, i really appreciate it and also the tutorials you are doing are great! Thumbs up and please keep up that great project. as you are saying if you are not coming from the field of automation directly but have some SW background it can be hard in the beginning to find information on proper PLC SW developing. For your neg points i was wondering if you have some advice for me… I 100% agree with you that this global variable thing is so out of time, also its totally annoying me, where as Beckhoff is even advertising it as a cool feature…
I come from embedded c developing and we were trying to avoid global variables wherever we could. Anyhow now i come across to read lots of sensors and acutate lots of devices so i have to do the famous “Device mapping”. At the beckhoff training as well as in some forums they all promote to have a GVL for the sensor reads and acutor outputs, but still it feels kind of nasty to me. I am rather tended to create the %I and %Q variables the decomposed abstract function blocks but also feel there might be some drawback later. Do you have maybe some advice for me on this or give me some insisghts on the design patterns you use for this?
best regards
alexander
Hi Alexander! I’m actually preparing a text about exactly this subject regarding global variables. I try to avoid them as much as possible. Unfortunately global variables are standard in the automation industry, mostly because modern software practices have not quite yet catched up in this field. There is no reason to put the I/O points in globals. My general patterns is that I define some business logic around the I/O points, instead of doing that in some outside logic. For example, if you have Beckhoff terminals then you can define function blocks for all the different terminals, and in where you put the actual I/O. These function blocks can do various logic such as error checking of the input signals (and possible actuation error signal monitoring as well). This pattern can be applied for any type of I/O, not just EtherCAT terminals but basically any device that you want to communicate with. In this way you can easily define tests for all variants of the inputs/outputs, and thus mock them in your tests to verify that your terminal function blocks behave in the right way. Even though all I/Os from EtherCAT are globals in memory you don’t have to treat them as it. Anyway, I’ll talk more about it in my text/video about global variables so stay tuned!
Good morning Jakob,
thanks for your fast reply and your suggestions, i fully agree with you and will think about your proposed pattern. Also i am very curious and excited about that new talk concerning the GVL. In that sense thanks and keep up the good work!
cheers
Hi, Google seems to like your Blog! Good on you. I came here now several times through search for solutions of some problems I regularly have in TwinCAT. So right now I would add something to your list of bad things: The TC3_EventLogger.
There are lots of good things about it, but I assume, that the Beckhoff Team developing this had not in mind, that we still work on Realtime-based controllers.
What I mean is grouping messages to zones or function groups and check each of them cyclically for any error, which still is raised in any of a configured group. Like cyclic filters directly within the PLC to use that for secure information about the status of a group.
What are your thoughts about this topic? Did I miss something, or do I have a misunderstanding at some point? How do you handle the Event System?
Hi Jakob,
I’m happy to find your blog and all the other resources on youtube. I am very new to twincat and PLC at all (coming from C++ and Rust).
Source control is currently my biggest problem when starting a new project for a team.
After applying your hints about git ignore and removing the tmc files from versioning, which I would also say is right, I run into a problem with global defined custom types. It seems that after switching the type to global, it disappears from the DUTs and is only available in the tmc file. So after checking out the project in a new workspace without tmc files, the build fails due to missing type in global “type system”. Or am I missing something else?
Cheers
Jacek