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.
From the perspective of TwinCAT and doing version control, there is nothing special about Git. Git is just one of many version control systems (VCS) out there. It’s created by this cool guy Linus Torvalds, who thought that the other version control software out there had their flaws. Doing version control with TwinCAT software there are many flavors, which of Git is one.
What all VCS have in common (other than doing, well, version control) is a way to specifically define which files should be untracked. How this is actually implemented differs in the different VCSs, but in git this is defined by a .gitignore-file, which is placed at the root of the project location which is to be tracked. Each line in this file specifies a pattern, which git uses to decide whether to ignore a specific path. This is necessary to avoid cluttering the VCS down with unnecessary files, which just take up space and make for unnecessary commits. Including a .gitignore-file is one of the items a TwinCAT developer doing version control should do.
TwinCAT 3, just as most integrated development environments, produces software artifacts that you normally don’t want to include in version control. But which files should we have version control of, and which should we skip? Beckhoff have a PDF to provide some of the answers, unfortunately it’s quite outdated and not complete. More recently, new additions have been made to the documentation regarding the different file types within a TwinCAT project. With this information and some experimenting, we can make a up-to-date gitignore file for TwinCAT.
| File extension | Description | Rationale |
|---|---|---|
| *.tpy | This file contains located PLC variables and their addresses as well as generic project information. This file is a relic from TwinCAT 2, although it can still be generated from a TwinCAT3 project (which needs to be explicitly configured). The replacement in TwinCAT3 is the *.tmc file | Artifact of the compilation process |
| *.tclrs | License response file | Unique for each target device. License files (and more generally target configuration) should be archived separately |
| *.compiled-library | Precompiled TwinCAT library project. | Should be supplied/installed separately as part of your build tool chain with the TwinCAT 3 installation + user projects |
| *.compileinfo | Compilation log file for the TwinCAT project. Also usable when analyzing core dumps. Artifact of the compilation process. | |
| *.tmc | TwinCAT Module Class. | TwinCAT 3 corresponding file to the TwinCAT2 tpy-file. Artifact of the (PLC project) compilation process. Don’t include this rule if: 1. You’ve got TwinCAT C++ projects, as the information in the TMC-file is created manually for the C++ projects. 2. You’ve created a standalone PLC-project and added events to it, as these are stored in the TMC-file. |
| *.tmcRefac | I’ve seen these popping up in the projects directories sometimes. | Artifact of the compilation process |
| *.library | TwinCAT library project with attached source. | See rationale for *.compiled-library |
| *.project.~u | Temporary file | Only backup files |
| *.tsproj.bak | TwinCAT project file backup | Only backup files |
| *.xti.bak | This is a backup of the *.xti-files. | Only backup files |
| _Boot/ | The TwinCAT boot directory, containing the compiled application | Files used for the target/PLC |
| _CompileInfo/ | Directory containing the compileinfo-files. | Artifact of the compilation process |
| _Libraries/ | Directory containing all libraries that the project depends of. | The libraries (*.compiled-library and *.library) are supposed to be supplied separately as part of your build tool chain with the TwinCAT3 installation + user projects, from which this folder will be created |
GitHub, worlds largest open source software repository, holds an excellent gitignore repository, with default gitignore files for various types of projects/IDE’s. I’ve submitted a pull request to GitHub to include a gitignore for TwinCAT 3 projects in this “official” gitignore repository, so that the TwinCAT community can use it. It’s not been approved yet (and the developers at GitHub do not seem to be in a hurry), but until it’s been approved it can be accessed from the pull request.
The entries in the gitignore-file for TwinCAT 3 are all specific for TwinCAT (possibly with the entry *.project.~u being the exception). However, as TwinCAT is integrated with Visual Studio it makes sense to also ignore the various files which should not be version controlled. GitHub hosts an excellent gitignore-file for this purpose. In your TwinCAT projects I recommend you to merge the TwinCAT3 gitignore-file with this VisualStudio gitignore into one common file, with one example being the gitignore-file for the TcUnit unit testing framework.