The default TwinCAT engineering tool (TwinCAT XAE Shell) is pretty great out of the box. However, there are some settings to make the development experience as efficient as possible. Some settings are a one time change and some are project based.
Although some of these settings need to be changed by project, a base project can be made so that the changes only need to be done once.
The following blog is using the latest 4026 build.
One Time Changes
The following settings can all be found in Tools->Options.
1. Dark Mode
It’s 2025, people! We deserve dark mode.
The general color theme must be changed along with the TwinCAT PLC editor theme to get the full dark mode experience. While it isn’t perfect (as seen by some light mode screenshots later in the blog), for the majority of development, a full dark mode experience can be enjoyed.
2. Tabs vs. Spaces
The winner of the endless debates is… both? We use tabs, but a tab inserts 4 spaces into the editor. This allows for more efficient development (tab does the work of 4 spaces) while maintaining a consistent structure (especially for git diff).
By going to Edit->Advanced->View White Space, the view shows the effect of a tab when used with this unchecked setting.
3. Header
I have added TwinCAT HMI to the header instead of relying on TwinCAT to contextually show it and TwinCAT XAE Project Variants because you never know what variant will be selected (or if variants even exist) when cloning a repository.
This can be accomplished by going to Tools->Customize.
4. Smart Coding
Have you ever ended up with a couple of garbage variables in your local variable declaration from pressing enter or clicking off a line of code you are not done with? Turning off this setting will let you move freely around your editor without having to worry about variables getting mistakenly declared.
5. Line Ids
This setting exists in the context of 4026 for a slightly different reason than it would for 4024. “Write Line Ids” was added in 4026 to remove the need for tracking the Line Ids in a file. The downside (which is big enough for us to change this default setting) is “even changes in whitespaces or line breaks will force an online change.” We have seen this cause some nuisance online change popups, so we have turned this to True, along with “Separate Line Ids” to store this information in a file that does not need to be tracked by git.
6. Independent Files
To best capture changes to hardware modules, each hardware module should be separated into its own file. This makes reading git diffs much easier.
As seen below, the default setting adds each hardware module to the main .tsproj file. As you can imagine, a lot of information is stored in this .tsproj file, so the more that can be split into off into its own file, the smaller each git diff will be to understand what exactly has changed.
All file types available should be saved as its own file.
Now, we have an independent file for each hardware module in which all of its settings are contained.
Please note – if this setting is changed, it will not affect the hardware modules that have already been added to the project. This must be done manually on each of the modules as seen below.
By Project
7. Variants
Project variants is a very powerful tool which may warrant its own blog at some point in time. Use this link for now.
Some automated things that can be done for project variants for switching back and forth between simulation on the local computer versus an actual machine on a target include:
- Changing the target
You never want to download the wrong project to a target! By switching the target automatically depending on the variant, this makes it a lot more difficult to do so. The simple example here shows the target switching from “Local” to “BECKHOFF-PANEL” depending whether the variant is “Simulation” or “Machine”.
- Disabling EtherCAT master
Removing hardware that does not exist in a simulation environment will allow the target to go into Run mode.
- Removing I/O link to axes
Another key aspect of simulating a project on a local computer is being able to test motion functionality. This can be done by removing the hardware link.
Changing parameters can also be helpful when testing code. Turning up axis limits (speed, acceleration, jerk, etc.) can speed up testing by not waiting the full time for an axis to complete its move.
8. Pinning
For long term maintenance of a machine, it is important to capture the exact project that is on a target. This includes both the TwinCAT build and libraries that are within the project.
This will allow for a user to get online with the PLC without being presented the Online Change dialogue box which leads to confidence in making logic changes if they are needed.
By pinning the project version, this will automatically open the correct TwinCAT build.
TwinCAT builds typically come with updated libraries. So, even if the TwinCAT build is pinned, the project still may use newer libraries if there is a newer build installed. By pinning libraries, this will make sure the same libraries are used.
Oftentimes libraries have dependencies that can be seen by expanding the library. These dependency libraries libraries should be pinned as well by either adding the libraries under References or resolving the placeholder in the “Placeholders” section.
As seen below, Tc2_Math has been added under references and has been set to the effective version and Tc2_MC2 has been resolved to the correct version using a Placeholder. Either option is valid here.
The full list of what can be done before a project is shipped can be seen here.
Conclusion
We hope at least one of these tips can be useful in your development. Please share any additional settings you found to be useful!
