Und der bisher überzeugendste Grund, Ihren TwinCAT-Workflow zu modernisieren.
Wer schon länger SPS-Software mit TwinCAT 3 entwickelt, kennt das Ritual: Libraries werden in ZIP-Dateien oder sogar USB-Sticks weitergegeben, die Versionierung passiert in Ordnernamen wie MyLib_v2_FINAL_fixed, und eine neue Maschine einzurichten heißt, die richtige Library-Version auf einem gemeinsamen Laufwerk zu suchen - das vielleicht aktuell ist, vielleicht auch nicht.
Die restliche Softwarewelt hat dieses Problem vor Jahrzehnten gelöst. Python hat pip. JavaScript hat npm. Rust hat Cargo. Jetzt hat TwinCAT Twinpack - und Version 1.4.2 macht es robuster, schneller und leichter in professionelle Entwicklungs-Workflows integrierbar als je zuvor.
Was ist Twinpack?
Twinpack ist ein Paketmanager für TwinCAT-3-Libraries. Anstatt .library-Dateien manuell zwischen Rechnern oder Projekten zu kopieren, deklarieren Sie Ihre Abhängigkeiten in einer Config-Datei und lassen Twinpack sie automatisch holen, cachen und installieren - direkt in TcXaeShell 3.1.4024 und 3.1.4026.
Das mentale Modell ist einfach: Sie sagen Twinpack, was Sie brauchen, und es kümmert sich darum, wo es das herbekommt, welche Version es nutzt und wie es installiert wird. Schluss mit „funktioniert nur bei mir"-Problemen.
Twinpack ist als CLI-Tool für CI/CD-Pipelines und als UI-Erweiterung in TcXaeShell verfügbar. Es ist Open Source und unterstützt On-Premises-Hosting über NuGet, Sie müssen also keine internen Libraries irgendwo extern veröffentlichen.
Warum das für TwinCAT-Entwickler wichtig ist
Die Automatisierungswelt hat beim Tooling traditionell hinter der Softwarebranche hinterhergehinkt. Das ist keine Kritik - es spiegelt die Natur des Bereichs wider. SPS-Code läuft auf Maschinen, die nicht leichtfertig aktualisiert werden können, und Stabilität hat höchste Priorität. Aber diese Vorsicht hat ihren Preis. Viele TwinCAT-Shops arbeiten noch ohne:
- Einen klaren Weg, Libraries über Projekte oder Teams hinweg zu teilen
- Automatisierte Tests oder CI/CD-Pipelines
- Reproduzierbare Builds: die Fähigkeit, ein Projekt neu zu bauen und exakt dasselbe Ergebnis zu erhalten
- Versionskontrolle für ihre Libraries
Twinpack adressiert all das direkt. Mit einer config.json im Repository können jeder Entwickler und jeder Build-Server twinpack restore ausführen und haben die richtigen Library-Versionen in Sekunden installiert.
Was in 1.4.2 neu ist
- Konsistente Fehlerbehandlung - robuster, wenn Library-Metadatenfelder wie Version oder Firma fehlen
- Trailing-Slash-Toleranz bei Repository-URLs
- DTE-Versions-Fallback - fällt sauber zurück, wenn das Visual-Studio-Automation-Interface vorhanden, aber defekt ist
- Race-Condition-Fixes bei der Auflösung von Packages für mehrere TwinCAT-Konfigurationen oder Branches gleichzeitig
- Bessere Fehlermeldungen und Config-Validierung -
config.jsonwird beim Laden mit klareren Fehlermeldungen validiert - Intelligenteres Restore für aktuellste Versionen -
null-Version inconfig.jsonwird jetzt korrekt zur neuesten veröffentlichten Version aufgelöst - Schnellere Katalog-Loads - Package-Metadaten aggressiver gecacht, API-Requests gebündelt und dedupliziert
- Repository-Toggle ohne Entfernen - Repositories können mit einem Flag deaktiviert und wieder aktiviert werden, statt gelöscht zu werden
- Monorepo- und Submodule-Unterstützung - Submodule in
config.jsondeklarieren, um mehrere Packages innerhalb eines Git-Repositories zu verwalten
Loslegen
Für Teams, die weitergehen möchten: Twinpack ist ein fundamentaler Baustein einer echten CI/CD-Pipeline für TwinCAT. Mit reproduzierbarer Abhängigkeitsauflösung können Sie:
- Eigene Libraries in eine Twinpack-kompatible Registry veröffentlichen
- Library-Versionen pinnen, sodass ein Build von vor sechs Monaten heute noch identisch kompiliert
- Auf einem CI-Server bauen und testen, ohne Libraries manuell auf jedem Agent zu installieren