When being in an early phase of a project, it’s common to use “latest and greatest” of the dependencies that your software relies on. In the beginning of a project, it’s usually low risk to built your system on the latest of everything as you’ve got plenty of time to make sure everything works as expected. I guess that’s one of the many joys of starting a new project, you are more free and can experiment more. But as you get closer and closer to the delivery of the project, it’s usually a good idea to start and “freeze” parts of the software. This includes everything from own developed libraries, TwinCAT supplied libraries, drivers, TwinCAT runtime and even the operating system on the target device (which anyways doesn’t change too often). Twenty years from now, I want to be able to compile and build the exact same executable binary that is running on that nice expensive machine right now. When I was close to delivery of a TwinCAT project, I got some problems related to this topic.

The scenario that occured to me was that I had a target PLC running TwinCAT 4020.28. I have two developer machines, one running 4020.28 and the other one had various versions, including a newer one (4022.4). Despite making sure that I always selected the correct version of the target in the TwinCAT remote manager, and even making sure I had the exact same source code on my two different developer machines, I always got this screen when logging in to the PLC after making a build:

TwinCAT online login

So, even despite I made sure I had the exact same software on both computers (running the same TAG from version control in GIT) and despite selecting 4020.28 in the TwinCAT remote manager on both machines the compiled executable was clearly different on both computers. I also made sure to follow Beckhoffs recommendations for source control, so that should not have an impact either. Why did the compiled binaries differ?

The reason is spelled libraries. When starting a new TwinCAT project and adding libraries (say for instance, for EtherCAT or Modbus), TwinCAT always defaults to selecting the latest installed version of the library on your developer machine. So this is not the latest installed version of the library for that particular release of TwinCAT XAE, thus this library setting is thus completely independent of the setting in the XAE remote manager. My problem above was due to the fact that the resulting binary could differ depending on whether I compiled it on my 4020.28 or 4022.4 machine. Firstly, as the code had been extensively tested with the 4020.28 libraries, this is what I wanted the machine to run with. Second, as the code was stable and major changes were unlikely, a frozen build seems more logic. Third, If I were to make any changes to the code (even 10-20 years from now), I want to be able to re-compile the exact same executable to every single byte so I can make changes only where it’s necessary to minimize risk.

This is easy to visualize by a simple default project with two different developer machines running different versions of TwinCAT XAE and opening the library references. With 4022.4:

TC3 4022.4 library references

And with 4020.28:

TC3 4020.28 library references

Clearly the effective version is different for all the libraries. The “*” is a placeholder meaning “newest version”. This is what we want to change to a fixed version that it corresponds to the latest library version for 4020.28. I’m lucky I actually still have a machine running 4020.28 as the latest release. What do you do if this is not the case? Neither the Beckhoff website nor the support could supply me with a list of what versions of the different libraries were installed with 4020.28, so another alternative (which I tested out) was to install 4020.28 in a virtual machine.

Changing the effective version of the library can be accomplished by selecting the library in the library references, going to the properties window and selecting the correct version.

Selection of library version

As you can see, it is possible for us to select either the version of Tc2_Standard supplied with 4020.28 (3.3.1.0) or 4022.4 (3.3.2.0). Select the correct version for all the libraries. This is how the library references now look like after selection of the latest library version for TwinCAT 4020.28.

Fixed library versions

As you can see, once I selected version “3.3.1.0” for the Tc2_Standard, TwinCAT made sure to resolve to this version for all other libraries that are dependent on the Tc2_Standard library.

Now, when building and compiling your TwinCAT software on different developer machines, you can always be safe and know that all dependencies are fixed and that the compiled binary will always look the same as long as you have the version of the TwinCAT XAE installed which corresponds to the version of the target runtime XAR. I’ve tried to build the executable on both my developer machines, and every time I login to the target (PLC), I never get the question of online change anymore.

While you’re at it, I highly recommend the introductory chapter on libraries on the Beckhoff website.

Library icon by Smashicons from www.flaticon.com
Old books by Jarmoluk from www.pixabay.com