Test driven development (TDD) doesn’t seem to be all too common among TwinCAT-developers, which is a shame. From my experience, TDD has a strong foothold everywhere among developers, but TwinCAT? Not so much. And I don’t blame them. There are TDD frameworks for C++, C#, Ada, Python and basically any other language and/or development environment. Do a Google search on the web on any programming language/IDE and TDD and you get thousands of results. Do the same for TwinCAT and you’re on your own.
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:
- non-assigned return values
- usage of object-oriented features
- unreachable code
This post has really not too much to do with TwinCAT, at least not directly. Instead, this post will be about a computer that’s close to my heart. So, despite not being directly related to TwinCAT, it’s about the computer which started my interest in software engineering, and ultimately led me to where I am today, therefore this post. The Commodore 64 was my first computer. The first version was released the same year I was born. Rewind the time back to the mid 80s, and this was the computer that everyone had back in those days. It was a fantastic machine back then. 1MHz clock frequency, amazing video-graphics, a whopping 64K of user RAM (hence the name) and fantastic sound (provided by the SID-chip). Despite the limited performance when judged by today standards, people were doing amazing stuff with it. The game and demo-scene was flourishing.
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!
When creating TwinCAT software I’ve come across a use case where I want to print out and store the actual version of the project that the program resides in. This can be pretty neat when you do version control, and for instance create a release of your program and want this information available somewhere in the output of the program. I’ve had this scenario when we had a project that was continuously updated. The test/integration team needed constant bug fixes/new software releases. As a software engineer I needed to keep track of what version the test/integration team were actually running at a specific time. By updating the version number in the project information I was being able to log the actual running version of the software in a database, which is important to know when going back to fault trace any strange behavior in a particular test.
PLCopen has released their coding guidelines for 61131-3 structured text (ST) some time ago. If you haven’t read that yet, I highly recommend you to do so! Even if I don’t agree with everything, it’s still a good read and a really good initiative to consolidate all the different coding guidelines that every vendor has for their 61131-3 ST environment.
Included in this is Rule L16 “Define the use of tabs”. Let me quote:
Use of tab character (ASCII code 9) should be avoided, and Programming Support Environment set to replace tabs with spaces
This is a common rule in many projects, as this simplifies copying of code into other contexts and makes the code less dependent on the user settings for display. Simply put, the visual interpretation of a tab character varies wildly. As the TwinCAT development environment integrates into visual studio, this is the place we need to do our change. I’m going to use visual studio 2015 community edition for this particular demonstration, but it should be more or less the same in the other versions of visual studio.
When integrating various forms of devices, generally speaking there are usually requirements that a certain degree of fault isolation of those devices needs to be done. EtherCAT slaves specifically can transmit emergency objects (EMCY) – a protocol inherited from CANopen. An emergency message is a high priority message sent once, and is triggered by an error event in the EtherCAT slave device.
Normally the emergency objects are showing up in the visual studio development environment, but that might not be enough. At one occasion I wanted to be able to handle the emergency objects in PLC code. Handling and reception of the emergency objects via the diagnosis history object will be explained in two parts – first we’re going to start with the theory of the diagnosis history object. In the second part we’ll create function blocks to implement handling of the diagnosis history object. The first part is out and can be located here!
When I develop software I mostly do the testing on my development computer. It is after all one of the big strengths of being able to run your code on a PC platform – it should more or less work the same on a PC based PLC. But then there is only so much testing you can do in your development machine, at some point you still end up needing to have the real hardware. I’ve already ended up with having some EtherCAT-slaves connected to the development computer so I decided I’ll go for a PLC to split the development computer and run-time environment completely. As Beckhoff has released PLCs from their embedded line with Windows 10 IoT Enterprise LTSB I though that was another reason good enough to buy one and experiment with it. Ended up with a CX5140 with 4gb of RAM and 32GB of flash-storage. Works like a charm out of the box, and I’ve already noticed some changes compared with running a controller with Windows 7 embedded. Since Windows 8 embedded, Microsoft have apparently replaced the FBWF (File-Based Write Filter) with the new UWF (Unified Write Filter). I’ll continue running/testing all my code on this controller, and will be posting new content to this blog as often as I can.
3S-Smart Software Solutions has since pretty long had a Raspberry Pi (RPI) target image available for their CODESYS runtime. The intention was to create something that you could buy very cheap, primarily for students and such to learn how to program 61131-3.
As I’m primarily working with TwinCAT3, which is based on CODESYS, I’ve been thinking about building a really cheap 61131-3 compatible PLC based on the RPI and the CODESYS target. I didn’t just want it to be one board laying around in my home, but I also wanted it to have the “industrial” feeling, and luckily I found a perfect development board + case for me to initialize the project. Now that it’s finished, I have a PLC running an EtherCAT master in the CODESYS runtime for almost no money at all.
Webpage is up! Here I’m going to have various information about different PLC programming tutorials. This will mostly be in the TwinCAT 3 and CODESYS environment. I’ve found out that there aren’t too many blogs/resources on TwinCAT 3 development. As I’m working with mostly TwinCAT-development every day at my job I thought it would be a good idea to share some of the knowledge I’ve aquired during as time has passed. Stay tuned!