And it’s the best reason yet to modernise your TwinCAT workflow.
If you’ve spent any time developing PLC software with TwinCAT 3, you know the drill: libraries get copied around in ZIP files or even USB sticks, versioning happens in folder names like MyLib_v2_FINAL_fixed, and setting up a new machine means hunting down the right library version from a shared drive that may or may not be up to date.
The rest of the software world solved this problem decades ago. Python has pip. JavaScript has npm. Rust has Cargo. Now TwinCAT has Twinpack - and version 1.4.2 makes it more robust, faster, and easier to integrate into professional development workflows than ever before.
What is Twinpack?
Twinpack is a package manager for TwinCAT 3 libraries. Instead of manually copying .library files between machines or projects, you declare your dependencies in a config file and let Twinpack fetch, cache, and install them automatically - directly inside TcXaeShell 3.1.4024 and 3.1.4026.
If you’ve never used a package manager before, the mental model is simple: you tell Twinpack what you need, and it handles where to get it, which version to use, and how to install it. No more “works on my machine” problems.
Twinpack is available as a CLI tool for CI/CD pipelines and as a UI extension integrated into TcXaeShell. It is open source and supports on-premises hosting via NuGet, so you don’t have to publish internal libraries anywhere external.
Why does this matter for TwinCAT developers?
The automation world has traditionally lagged behind the software industry when it comes to tooling. That’s not a criticism - it reflects the nature of the domain. PLC code runs on machines that can’t be updated carelessly, and stability is prized above all else. But that caution has come at a cost. Many TwinCAT shops still operate without:
- A clear way to share libraries across projects or teams
- Automated testing or CI/CD pipelines
- Reproducible builds: the ability to rebuild a project from scratch and get the exact same result
- Version control for their libraries
Twinpack directly addresses all of these. With a config.json in your repository, any developer or build server can run twinpack restore and have the correct library versions installed in seconds.
What’s new in 1.4.2
- Consistent error handling - more robust when library metadata fields like version or company are missing
- Trailing slash tolerance on repository URLs
- DTE version fallback - gracefully falls back if the Visual Studio automation interface is present but broken
- Race condition fixes when resolving packages targeting multiple TwinCAT configurations or branches simultaneously
- Better error messages and config validation -
config.jsonis validated on load with clearer error messages - Smarter restore for latest versions -
nullversion inconfig.jsonnow correctly resolves to the latest published version - Faster catalog loads - package metadata cached more aggressively, API requests batched and deduplicated
- Repository toggle without removal - repositories can be disabled and re-enabled with a flag rather than deleted
- Monorepo and submodule support - declare submodules in
config.jsonto manage multiple packages within one Git repository
Getting started
For teams wanting to go further, Twinpack is a foundational piece of a proper CI/CD pipeline for TwinCAT. With reproducible dependency resolution you can:
- Publish your own libraries to a Twinpack-compatible registry
- Pin library versions so a build from six months ago still compiles identically today
- Build and test on a CI server without manually installing libraries on each agent