I’ve been using TwinCAT 3 more or less since it was released, and since then it has become such an integrated part of my daily work that it’s my main software development platform. I like to develop software using TwinCAT 3, but I’ve come to the conclusion that there are some features I miss. I’m not the only person that uses TwinCAT 3, and this video is made in collaboration with someone that has vastly more experience in industrial automation than me – Peter Kurhajec. As we both work with TwinCAT 3 on a daily basis, we decided to do a video with the title “4 things we want in TwinCAT 4”. Consider this as a wish list for a future version of TwinCAT, so some kind of dream session.
4 things we want in TwinCAT 4
I received information from Beckhoff that they will introduce a standalone system manager with TC 3.1.4026. It will provide access to Automation Interface functionalities without DTE-Interface of
Visual Studio via CLI, C# or PowerShell.
Besides that, I think Beckhoff is more progressive that other supliers introducing features of traditional software development into the world of industrial automation. However, I experience the majority of PLC developers still prefers the “old style” and has problems working with OOP, version control, build pipelines etc.
I’m looking forward to that! Thanks for information.
You are right that developing the program language is a key to be the number one on the market, there shouldn’t be too much norm for programming languages like the IEC 61131-3. Just copy the ideas of good program languages. In my opinion Microsoft with C# is the best example. It is such nice to have good colors in your code and a nice Intellisense. In the future the classic PLC programmer will die out and everyone is thinking OOP.
Furthermore, the cooperation with DevOps systems like Azure DevOps are key features, builds and code reviews should be easier. The Beckhoff HMI is on a good way with their NuGet packages but there is still a lot to do for easy use by non-web-developer. From my side some more suggestions are e.g.
– Beckhoff should boost the community cause in other languages you find nearly every problem online on stack overflow and for PLC problems there is nearly nothing
– Some companies also boost their customers with video tutorials which is very helpful and would be a big plus to use TwinCAT instead other systems. We all know that the documentation is very weak so finally we need the support.
– The biggest weakness is that Beckhoff has no release notes. How the hell should I know what’s new? Ok I will ask the support. Again…
Another issue, from my opinion, is there are no change logs available for the different TwinCAT versions or libraries. I experienced a lot of problems with the Tc3_JsonXml library, having features work in one version of TwinCAT, but not anymore in the next.
I salute the TcOpen project greatly, but I think Beckhoff should really go along on the open source train much more.
These days I work in a firm (Just started two months ago) that uses the Beckhoff platform.
Prevoiusly I had experience with Codesys so the language was not a problem.
In the last firm where I worked was the first time I had to use Siemens… I hated every second of it, the IDE is terrible, the language compared to the codesys oop extension is so weak…
Other programmers in that firm were using the B&R platform where you can program with c++, that looks really awesome, just having ANSI C++ as your plc programming language is just perfect.
Maybe we should all switch to B&R…
Definitely have to try B&R out!
AllBR.com confirmed 😉
Just saw that their development environment costs money, so no B&R for me (even though they have a time-limited free test-license).
The trial is 30 days and you can get a unlimited number of renews. We used it in a couple of projects and although the compiling is a bit slugish it works great! Version control is easy. Plain txt no xml tags. Als a lot of functions out of the box which require a license on Beckhoff.
Worth checking out!
In TwinCAT you can code in c++ too. You have to use a full Visual Studio installation and TwinCAT Integration into it.
https://www.beckhoff.com/en-gb/products/automation/twincat/tc1xxx-twincat-3-base/tc1300.html
But in TwinCAT 3.1 you can also write you Application in C++ or am I missing something?
You can, but there’s a fair amount of added friction when working with C++ code compared to PLC code. It’s kind of a second-class citizen in terms of integration into the whole TwinCAT environment.
I fully agree with the points in the video.
I only work with twincat occasionally, but a lot with C# and I was annoyed about the XML file structure too.
More and more people are dealing with Python or Raspberry Pi as a hobby. Every major programming language is just text-based and can usually be controlled via CLI. Text-Based structured text definitely makes sense.
Martin’s point in the comments is also correct, I think there are still people who like to work with FUP programming and ZIP files, and you can’t rule out these people either.
It will therefore probably remain with a graphical editor for a long time.
Should there be a future solution based entirely on Text-Based structured text, I could just write everything in Visual Studio Code or the IDE of my choice.
My customers are losing faith in Beckhoff.
If this is an issue others have seen it may be relevant to this forum. If not I can move it to the appropriate forum.
Does anyone else see stability issues when running Beckhoff PLC’s (TwinCAT 3 any build) continuously for weeks on end? I have a customer who will restart their machines with Beckhoff PLC’s once a week to prevent comms issues to I/O, HMI (Indusoft), or just general Beckhoff cpu latency issues.
Randy, this is interesting.
We build Beckhoff-based systems for steel plant applications and they have to run for months at time with no performance issue. If there’s an industry adverse to modern automation / software concepts it is the steel industry, but we have been able to successfully deploy Beckhoff and after an initial resistance the feedback is very positive.
We have, however, pretty much decided to abandon the CE-based CPU except for very small, mostly stand-alone systems because it seems that the OS has issues simply defending the core app when the CPU gets “attacked” via Ethernet (requesting data is enough to introduce unacceptable latency in the user program).
Maybe this is the issue you’re having, but if that were the case, then using a CX51xx series CPU pr better could be the answer. We have applications that use those CPUs and have been running for one-year with sub-ms scan times, no latency issues and no need to reboot at all.
Notice that the cost of Beckhoff CPUs compared to others is low enough that you can have a top-of-the-line CPU for less than the cost of a mid-level CPU with other brands.
My two cents…
Even as a TwinCat beginner, I can immediately agree particularly with the first three points. Already we are see issues with shared development, build and deployment because of the way the ST code is stored.
The lack of a CLI and the heavy footprint of Visual Studio is awkward. I’ve worked with .NET since the start, it’s been a joy to see that move out of the clutches of VS more recently.
I was particularly interested in the OOP features, and they feel a little like a they’ve been bolted on. I need to explore this further, but the fact that variables have to be statically declared seems to limit the benefits of using interfaces.
Thank you very much for your video.
I myself have been working with Codesys since 1998, with TwinCAT 2 since about 2004 and with TwinCAT 3 since about 2016, so I have experienced quite a bit. I am basically excited about the OOP possibilities of Beckhoff (compared to other companies), but as you rightly said, the next step might follow soon now.
I fully agree with all your 4 points: They would make working with it much easier once again. But we must never forget: This is a real-time platform. For security reasons, not everything can be allowed, as in Java or C#. At the beginning of our work with TwinCat 3, we overdid it a bit with the possibility of dynamic object creation. We had built whole buffers with it, which constantly created and deleted objects. At some point, the memory was so fragmented that there was no room for a new, larger object. Also, the new command took longer and longer. We had to rebuild this afterwards (we use the delete command only very rarely).
In this context I would like to have a possibility to manually start a garbage collector. This could be during a standstill of the machine, where task overruns would not be a problem.
We have also always been annoyed by the missing release notes. It’s really, really tedious. So I have no choice but to have a ticket entered for each item and then ask regularly what the status is.
We from our side should perhaps organize ourselves somehow in a community, in order to exchange ourselves better (pass on knowledge).
Hi Stefan! Thanks for your feedback. Sounds like you’ve really experimented with the dynamic memory allocation features in TwinCAT. I fully agree that this is a different industry and we have to be careful.