My main software development machine is getting really old and tired so I decided to build a new one. When I was younger it was a lot of fun to build computers, but now that I’m old, boring and grey I haven’t had the time nor the motivation to build a computer but rather just buy one that’s pre-built. This time I have decided I will go back to my roots and build the computer myself. Join me on the journey of building a new software development machine!
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.
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.
We are at the final post of this series of continous integration and delivery with TwinCAT. We’ve accomplished setting up & configuring the automation server, created a TwinCAT test library project and wrote a small batch script that will be launched every time a new push has been done to the GIT repository for the library project. Now it’s time for us to write the program that will do the actual static code analysis.
In the previous post we did some installation and configuration of software to support us in the automation of doing static code analysis of TwinCAT software. We have reached a state where a Jenkins job is launched as soon as our TwinCAT library project is pushed to the GIT-repository. Even though we have a Jenkins job defined for static code analysis of TwinCAT software, it’s not doing anything yet. This will be our next step.
I like to have things structured and ordered. This does not only include the obvious stuff as making sure to pair and match all socks after laundry, but it also includes the TwinCAT software I develop, more specifically own developed TwinCAT libraries. “Whaaat??? What does sorting socks have to do with TwinCAT software?” you might wonder. I’m glad you asked.
In the previous post we were introduced to the concept of continous integration and
continous delivery (CI/CD) in the world of PLC software development, more specifically TwinCAT development. The conclusion is that certain processes in the process of creating software can and should be automated. As an example, we set the goal of automating static code analysis of all TwinCAT software. In this part of the series of CI/CD we will look into some practical matters of installing and configuring the necessary software.
The development of PLC software needs to enter the 21st century. With the increased complexity of developed systems, the amount of software that is going to be developed for a given system will continue to increase. PLC development is partially living on an isolated island, and while most other areas of software development have been modernized, the world of PLC software engineering development is going significantly slower. When we develop more software, there is a need for more automation to remove unecessary manual handling and in the end increase the quality of the software we develop. Now I know that you can’t compare developing software for a web shop with developing software for a PLC that can run software that is critical and maybe even be safety-critical and one line of code can be the difference of life and death. However, developing reliable and robust software and adhering to modern software development processes and tools does not mean they do rule each other out. You can pick both.
Together with TwinCAT release 4022.0 Beckhoff released their product “TE1200 – TC3 PLC Static Analysis“. It’s a tool integrated in the development environment to help the developer increase the quality of the code. Other than being able to set your own naming conventions for the code, TE1200 can be used for various rule checks, for example:
I guess you’ve seen the news, TwinCAT 3.1.4022.0 has been released. At one point or another, when developing TwinCAT software you eventually end up in wanting to write code for the latest runtime, but still being able to do software bug fixes/releases for code running on older TwinCAT runtimes. I thought it would be good to quickly share with you how you can work and develop multiple projects developed for different runtime versions but from the same developer machine!