Some time ago I wrote a post about developing code for different runtimes, and since then I’ve come to the realization that there is so much information missing in that blog post that I simply needed to write another one. What’s even worse is that the information regarding development, deployment, and just general handling of several TwinCAT versions on the Beckhoff website is not that good. I’ve talked to numerous automation engineers regarding this topic, and everyone seems to have a different understanding about it. As I was working in a development project that had many PLCs (hundreds!) with different versions of TwinCAT, I finally had a good excuse to dive into the details of this. With this blog post, I’d like to share some of the facts and misconceptions.
Dear TwinCAT/PLC developers,
I’m very happy to announce the release of the TcUnit-Runner, an open-source tool for integration of TwinCAT unit tests into a CI/CD toolchain automation server such as Jenkins. When TcUnit, the TwinCAT unit testing framework, was released back in December of 2018 I would never have imagined how widespread it would get. Since then, I’ve received e-mails from PLC developers every week with questions, improvement suggestions or just gratitude for this open-source software. The TcUnit framework has found its way into the full range of projects ranging from small machines to multi-billion € projects. With this response, I would say that there definitely is a need for unit testing in the world of automation. The adoption of TcUnit into TwinCAT projects across the globe has motivated the further development of TcUnit. One limitation of the TcUnit framework was that it was only possible to run the unit tests locally on your development machine (or PLC), and thus needed to be run manually every time a change in the software was made. Modern software practices advocate that software development should adhere to the practices of continuous integration/continuous delivery (CI/CD), so that tests would be run automatically when committing changes to version control. Thus, TcUnit-Runner was developed.
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.
Doing version control is a natural part of any software engineers daily work. Doing version control for PLC software has historically mostly been hard, if not impossible. As many automation manufacturers store all software in binary blobs it has not been suitable for version control. Sometimes there have been proprietary solutions available, but it’s not until recently that a shift has started where source code is stored in plain text. For version control, Git has gained more and more popularity for over a decade.
Logging various form of data is common practice and is done in some form in more or less every industrial application. There are various ways to store the data such as databases and different cloud services. However, sometimes you just want to stick to the basics and store data as a file, for instance as comma separated values (CSV). Depending on the amount of data that needs to be written, it’s usually not the best idea to do a lot of writes to the PLCs local drive because of wear and accessibility, but rather to a network drive.
In one subsystem of the extremely large telescope (ELT) there are 132 Beckhoff PLCs running TwinCAT3, and this large amount has brought some interesting challenges to the ELT project. Upgrading the entire system one PLC at a time would be time consuming and prone to errors. When there is need for automation, the TwinCAT automation interface comes to the rescue. In the final part we go through the steps necessary to do the actual build and deployment to the software to all PLCs.
In part one of this series of posts an introduction was given to a very specific problem that needed to be solved in the ELT project. When doing software maintenance of a subsystem consisting of 132 PLCs, it’s not viable to do it manually as it would be prone to errors and be quite time consuming. In this part of this series we will investigate the more practical problems that needs to be solved for us to do the automated deployment of the software to all PLCs.
The extremely large telescope (ELT) is a telescope currently under design/construction. With its 39 meter wide segmented primary mirror, once finished, it will be the largest optical telescope built. Once it will start to collect photons it will open new frontiers and extend mankinds knowledge about the universe. It’s a project with collaboration across the globe involving many universities, industries and organizations. It’s a mighty instrument including many fields of engineering such as electrical-, mechanical-, optical- and software engineering. Alright you get it. The ELT is big, cool and everything… but what does that have to do with the TwinCAT automation interface?
Found this information on the TwinCAT LinkedIn-group, but thought it’s good to share it with everyone else. Beckhoff unfortunately don’t provide release notes with updates/bug fixes/features to new releases of TwinCAT. They have however recently added a new RSS-feed so that it’s possible to follow new releases of TwinCAT and the different supplements. Apparently this is going to be added to the Visual Studio start page from TwinCAT 3.1.4024, which hopefully will be released in the not-too -distant future. The address to the feed is http://www.beckhoff.com/english/rss/beckhoff-twincat-rss-feed.xml.
I use a plugin to chrome called RSS Feed Reader which I find really nice. Just install it (you don’t need to register for an account), and add the feed to the plugin. Next to the address bar in chrome you will now automatically see all news from Beckhoff conveniently.