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.
Name a few things that software developers always have strong opinions about and naming conventions on code is one of the things that surely will come up. What lengths for identifiers should we use? Should we use hungarian notation? CamelCase or under_score case? While programming guidelines covering these topics have been existing since the rise of the early programming languages, they are much less common for industrial control.
Initially the only one that I found was Beckhoffs for TwinCAT3. Most of Beckhoffs libraries and example code used this, even though even Beckhoff themselves have not been consistent. More recently PLCopen have released their coding guidelines written specifically for IEC61131-3. Just out of curiosity I decided to compare the two standards and their take on naming conventions, and comparing them to my own personal opinions.
I’m very happy to announce the release of TcUnit – an unit testing framework for TwinCAT3. TcUnit is an xUnit type of framework specifically done for Beckhoffs TwinCAT3 development environment. This is another step in the direction of modernizing the software development practices in the world of automation.
Before dwelling into the details, let me tell the background of this project. In 2016 the development of the CorPower wave energy converter (WEC) was in an intensive phase. Software was being finalized, tested and verified for delivery. In a late phase of the project some critical parts of the software needed to be changed. The changes could be isolated to a few function blocks (FB), so in an initial phase the tests simply consisted of exporting those FBs to a separate project and running them locally on the engineering PC. The FBs were changed and executed in the engineering environment, and then online-changing the inputs and seeing whether the expected outputs were given. After doing this for a couple of hours an important question was raised:
Shouldn’t this be automated?
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.
Most people who have developed software have at some point or another used virtualization technology. Software development for PLCs in a virtual environment is often overlooked, since PLC development is so close to the hardware. Nevertheless, there are still advantages. Working for several projects with various requirements, but where a Beckhoff PLC/TwinCAT was the common delimiter, made me ask myself “How much use of virtualization can I do for TwinCAT software development?”
In my earlier posts I’ve written about development of TwinCAT software using test driven development (TDD), by writing unit tests. One of the advantages by adhering to the process of TDD is that you mostly will end up with function blocks (FBs) which have limited but well defined responsibility. Eventually you will however have FBs that are dependent on other function blocks. These could be FBs that are your own, or part of some 3rd party library, for example a Beckhoff library. Further, what if this external FB relies on some other functionality such as external communication using sockets that we have no control of? The external FBs should already be tested, we’re only interested in making sure our unit tests test our code! What do we do? A solution to this is to mock the external functionality and use dependency injection.
While doing software development in TwinCAT, I have always been missing some sort of generic data type/container, to have some level of conformance to generic programming. “Generic programming… what’s that?”, you may ask. I like Ralf Hinze’s description of generic programming:
A generic program is one that the programmer writes once, but which works over many different data types.
I’ve been using generics in Ada and templates in C++, and many other languages have similar concepts. Why was there no such thing available in the world of TwinCAT/IEC 61131-3? For a long time there was a link to a type “ANY” in their data types section of TwinCAT3, but the only information available on the website was that the “ANY” type was not yet available. By coincidence I revisited their web page to check it out, and now a description is available! I think the documentation has done a good job describing the possibilities with the ANY-type, but I wanted to elaborate with this a little further.