Kurzfassung Creator 1.8 bringt eine Kommandozeile und einen MCP-Server für KI-Agenten. Beides ist das direkte Ergebnis einer bewussten Architekturentscheidung vor 18 Monaten: weg von der Abhängigkeit vom Beckhoff Automation Interface, hin zu einem eigenen Parser und Semantikmodell. Damit haben wir volle Kontrolle über Codeanalyse und Codegenerierung, unabhängig von IDE, Hersteller oder dem, was Beckhoff als nächstes ankündigt. Wer ein Unternehmen mit SPS-Software betreibt und sich darüber noch keine Gedanken gemacht hat, sollte weiterlesen.
Wie wir zu einem MCP Server gekommen sind, lohnt sich zu lesen. Weiter unten gibt es ein Demo-Video.
Beckhoff hat PLC++ auf der SPS 2024 angekündigt. Structured Text als reines Textformat, kein XML mehr, keine .TcPOU-Dateien mehr, und entscheidend: die Zukunft des Automation Interface bewusst offengelassen.
Für die meisten Unternehmen, die TwinCAT einsetzen, ist das zunächst nur eine Randnotiz. Für uns war es ein konkretes Signal zum Handeln.
Creator war von Anfang an in die TwinCAT XAE-Umgebung eingebettet und hat sich jahrelang auf das Automation Interface gestützt, um die wesentliche Arbeit zu erledigen: Deklarationen finden, Implementierungen auflösen, Funktionsblock-Hierarchien navigieren. Das Automation Interface ist leistungsfähig und für IDE-integrierte Workflows gut geeignet, erfordert aber eine geöffnete IDE, ist an Windows gebunden und COM-basiert. Das sind Einschränkungen, die für IDE-unabhängige oder plattformübergreifende Szenarien nicht passen. Wenn Beckhoff es für PLC++ wesentlich verändert, hat jedes darauf aufgebaute Werkzeug ein Problem.
Wir haben entschieden, dieses Problem zu lösen, bevor es eintritt.
Das Fundament: AML als Maschinenbeschreibungssprache
Bevor wir auf die Änderungen eingehen, lohnt es sich, etwas zu erklären, das sich nicht geändert hat: Wir verwenden AutomationML (AML) seit Beginn als Grundlage von Creator.
AML ist ein offener XML-Standard für den Austausch von Engineering-Daten zwischen Werkzeugen. Für uns erfüllt er einen konkreten Zweck: Er beschreibt die Struktur einer Maschine (Units, Equipment, I/O, Achsen, Sequenzen) auf abstrakte, herstellerneutrale Weise. Wenn Creator genutzt wird, um die mechatronische Struktur zu definieren, wird diese Struktur in einem AML-Dokument abgelegt. Dieses Dokument ist die maßgebliche Quelle dafür, woraus die Applikation besteht, getrennt von jedem generierten Code.
Diese Trennung ist entscheidend. Sie bedeutet, dass Code generiert, neu generiert, migriert oder für ein vollständig anderes Zielsystem erzeugt werden kann, weil die Beschreibung sauber ist und die Generierung ein davon unabhängiger Schritt bleibt.
Was wir gebaut haben: Parser und semantisches Modell
Das konkrete Problem, das wir lösen mussten: Creator hat sich bisher auf das Automation Interface gestützt, um TwinCAT-Quellcode zu navigieren. Wenn wir wissen mussten, ob ein Funktionsblock von einem bestimmten Basistyp erbt oder welche Methoden eine Unit nach außen anbietet, haben wir das Automation Interface gefragt.
An dessen Stelle haben wir einen eigenen Parser gebaut und daraus ein semantisches Modell aufgebaut.
Der Parser liest TwinCAT Structured Text-Quelldateien direkt ein. Für das klassische XML-eingebettete .TcPOU-Format extrahiert er den ST-Inhalt und baut ein Modell aus Namespaces, Funktionsblöcken, Methoden, Properties, Interfaces und Vererbungsketten auf. Das semantische Modell unterstützt genau die Abfragen, die wir brauchen: dieselben Informationen, die das Automation Interface für die Codenavigation liefert, und darüber hinaus.
Das Automation Interface ist nicht verschwunden. Creator nutzt es nach wie vor für die Visual Studio-Erweiterung, und das wird sich nicht ändern. Aber es ist nicht mehr der einzige Weg. Wir haben jetzt eine Codegenerierungs-Engine, die unabhängig von der IDE arbeitet, und beide Ansätze basieren auf demselben Grundmodell. VS-Erweiterung und CLI/MCP-Server sind damit zwei Ausprägungen desselben Systems, keine getrennten Werkzeuge mit getrennten Implementierungen.
Das bedeutendste Element darunter ist die Abstraktionsschicht: ein Codec-Interface, das trennt, was Quellcode inhaltlich ist, von der Frage, wie er auf der Festplatte abgelegt ist.
ISourceCodec
├── TwinCatPlcCodec (.TcPOU / .TcDUT / .TcGVL, das klassische XML-Format)
└── StructuredTextCodec (reine .st-Dateien, PLC++, Simatic AX und andere, die diesen Weg gehen)
Beide Codecs speisen dasselbe semantische Modell. Dieselbe Codegenerierungslogik, dieselbe AML-gestützte Struktur, dieselben CLI-Befehle, alles unabhängig davon, welcher Codec verwendet wird.
Das bedeutet, Creator ist in seiner Architektur kein reines TwinCAT-Werkzeug mehr. Es kann Framework-konformen Structured Text für jeden Hersteller generieren, der reine Textdateien als Quelltextformat verwendet. Simatic AX tut das bereits. PLC++ wird es tun. Andere werden folgen.
Die CLI
Sobald das semantische Modell und die Codec-Abstraktion standen, war eine Kommandozeilenschnittstelle der nächste logische Schritt.
zkcreator ist eine CLI, die jede Creator-Operation (Units anlegen, Equipment zusammenstellen, Achsen hinzufügen, I/O verwalten) ohne geöffnete IDE zugänglich macht. Der Aufruf erfolgt gegen ein Projektverzeichnis: Das Werkzeug liest das AML, lädt das Semantikmodell aus den Quellen und führt die gewünschte Operation aus.
Interessant ist dabei nicht nur der IDE-unabhängige Betrieb, sondern was dieser ermöglicht.
Jeder CLI-Befehl ist direkt auf eine AML-Operation abgebildet, die durch echte Schemadefinitionen abgesichert ist. Die Befehle werden aus der AML-Bibliothek generiert, nicht von Hand geschrieben. Kommt ein neuer Equipment-Typ zur AML-Bibliothek hinzu, wird der zugehörige CLI-Befehl automatisch aus demselben Schema erzeugt. Gleiche Beschreibungen, gleiche Attributbindungen, gleiche Validierung. Die CLI ist eine direkte Abbildung des Maschinenmodells.
Einige Beispiele:
# Neues Automatisierungsprojekt anlegen
zkcreator zautomationproject-create --name Zeugwerk_Quickstart
# Unit hinzufügen
zkcreator zunit-create --name Foerderband
# Digitalen Ausgang zur Unit hinzufügen
zkcreator digitaloutput-create --name FoerderAntrieb --unit <unit-guid>
# Alle Objekte im Projekt auflisten (JSON-Ausgabe für Scripting)
zkcreator list-objects --output json
# Projekt validieren (vollständiges Re-Parsing, meldet Syntaxfehler)
zkcreator validate-project
Das Ausgabeformat ist frei wählbar: menschenlesbar für den interaktiven Einsatz, JSON für Scripting und Weiterverarbeitung.
Der MCP-Server
Die CLI ist nützlich. Der MCP-Server ist der Punkt, an dem es wirklich interessant wird.
MCP (Model Context Protocol) ist das Protokoll, über das KI-Agenten wie Cursor, Claude Desktop und andere externe Werkzeuge aufrufen. Ein MCP-Server stellt eine Menge von Tools bereit, die der Agent während einer Konversation aufrufen kann. Der Agent entscheidet, wann er sie aufruft; der Server führt sie deterministisch aus.
Creator 1.8 bringt einen MCP-Server, der auf der CLI-Engine aufbaut:
zkcreator mcp
Mehr ist nicht nötig. Der Server startet über stdio, registriert alle Creator-Tools, und jeder MCP-kompatible Agent kann sie verwenden. Die Tools werden, wie die CLI-Befehle auch, aus dem AML-Schema generiert. Beschreibungen, Parameter, Validierung: alles aus derselben Quelle abgeleitet, die die CLI antreibt.
Das Ergebnis ist, dass ein KI-Agent eine vollständige TwinCAT-Applikation von Grund auf aufbauen kann:
- Agent ruft
zautomationproject_createauf → Projektgerüst und Solution-Dateien werden auf der Festplatte angelegt - Agent ruft
zunit_createauf → Ein Unit-Funktionsblock wird mit der korrekten Zeugwerk Framework-Vererbung generiert - Agent ruft
digitalinput_create,zequipmentactuator_createusw. auf → I/O- und Aktuatorcode wird deterministisch erzeugt - Agent ruft
sequence_createauf → Zustandssequenzen werden korrekt angelegt und mit den nötigen Dateien befüllt - Agent ruft
validate_projectauf → Vollständiges Re-Parsing bestätigt fehlerfreien Code
Der Agent schreibt diesen Code nicht durch Raten. Er ruft Werkzeuge auf, die jedes Mal strukturell korrekten, Framework-konformen Code erzeugen. Das LLM übernimmt die Intention (was soll diese Maschine tun); der MCP übernimmt die Struktur (wie der Code aufgebaut sein muss).
Das folgende Video zeigt die Demo.
Das Dokumentationswerkzeug: Logik korrekt umsetzen
Deterministische Strukturgenerierung löst eine Hälfte des Problems. Die andere Hälfte ist die Logik: Wenn der Agent die eigentlichen ST-Implementierungen schreibt (Zustandsübergänge, Sequenzbedingungen, Aktuatorsteuerung) muss er die korrekten Methodensignaturen, Property-Namen und verfügbaren Überladungen für Framework-Typen kennen.
Sprachmodelle kennen die Zeugwerk Framework-API nicht zuverlässig. Sie sollten nicht darauf angewiesen sein, sie aus bestehenden Quelldateien zu erschließen.
Der MCP-Server von Creator 1.8 wird ein get_doc-Tool enthalten, das aktuelle Dokumentation für jeden Framework-Typ abruft:
get_doc(type_name="ZApplication.Sequence#Await2")
→ gibt die vollständige Methodensignatur, Parameter, Beschreibung und Beispiele zurück
direkt aus der veröffentlichten Framework-Dokumentation
get_doc(type_name="ZEquipment.DigitalInput")
→ gibt die Typ-Zusammenfassung, Properties und geerbte Methoden zurück
Die Dokumentation stammt aus derselben Quelle, die wir für menschliche Entwickler pflegen: doc.zeugwerk.dev. Sie ist immer aktuell, vollständig und enthält Beispiele aus der Praxis. Der MCP-Server macht sie maschinenlesbar in einer Form, die Agenten bei Bedarf direkt abrufen können.
Die Kombination schließt den Kreis: Strukturgenerierung, bei der dem Agenten keine Fehler unterlaufen können, plus API-Dokumentation, die ihm ermöglicht, korrekte Logik zu schreiben.
Warum das über Beckhoff hinaus wichtig ist
Wir haben diese Arbeit wegen PLC++ begonnen. Aber die Architektur, bei der wir gelandet sind, hat Konsequenzen, die weit über die Anpassung an ein sich wandelndes Ökosystem hinausgehen.
Die Codec-Abstraktion ist keine theoretische Übung. Ein Projekt, das heute Simatic AX verwendet, kann von derselben Creator-Engine angesprochen werden. Jeder Hersteller, der reine ST-Textdateien ausliefert (und die Branche bewegt sich in diese Richtung), kann mit derselben Toolchain bedient werden. Das AML-Dokument, das die Maschine beschreibt, ändert sich nicht, wenn sich das Dateiformat des Quellcodes ändert.
Das MCP-Interface macht Creator-Funktionalität für jeden Agenten in jeder Umgebung zugänglich. Nicht nur Cursor. Nicht nur Windows. Nicht nur Visual Studio. Überall, wo MCP unterstützt wird, lässt sich ein Creator-gestützter Agenten-Workflow betreiben.
Und die Dokumentationsanbindung bedeutet, dass Agenten, die mit dem Zeugwerk Framework arbeiten, sich nicht auf ihr Vorwissen aus dem Training verlassen müssen. Sie fragen die aktuelle Dokumentation ab. Das ist ein wesentlicher Unterschied in der Zuverlässigkeit: Der Agent prüft Methodensignaturen nach, anstatt sie zu erfinden.
Was das bedeutet, wenn Sie eigenes PLC-Tooling aufbauen
Einen Parser und ein semantisches Modell für Structured Text zu entwickeln ist keine triviale Aufgabe. Das vollständige Typsystem, Vererbungsketten, Interface-Auflösung und Namespace-Scoping korrekt abzubilden ist aufwändig, wenn man direkt auf Quelldateien arbeitet und keine IDE im Hintergrund hat.
Wir bauen diese Infrastruktur seit Jahren. Das semantische Modell, das Creator’s CLI und MCP antreibt, ist dasselbe wie das hinter der VS-Erweiterung. Es ist erprobt, wird aktiv gepflegt und kommt mit den Sonderfällen zurecht, die reale TwinCAT-Projekte produzieren.
Wer ein Unternehmen mit SPS-Software betreibt und überlegt, was eine mögliche Veränderung des Automation Interface für die eigene Werkzeuglandschaft bedeutet, oder wie das eigene Framework für KI-Agenten zugänglich gemacht werden könnte, dem können wir konkret weiterhelfen. Nicht nur mit unseren eigenen Produkten, sondern beim Aufbau der Parser- und Semantikschicht, die dafür notwendig ist.
Was Creator 1.8 bringt
Hier ein Überblick über den Umfang des Releases:
zkcreatorCLI: Vollständiger Kommandozeilenzugriff auf alle Creator-Operationen. UnterstütztTwincatPlc- undStructuredText-Codecs via--codec. JSON-Ausgabe via--output jsonfür Scripting.zkcreator mcp: MCP-Server über stdio. Alle CLI-Tools stehen als MCP-Tools bereit, Beschreibungen und Parameter werden aus dem AML-Schema generiert.get_doc-Tool: Dokumentationsabfrage für jeden Zeugwerk Framework-Typ, mit Auflösung einzelner Typ-Member (Typ#Member-Syntax).validate_project-Tool: Vollständiges Re-Parsing mit Syntaxfehlerberichten. Aktualisiert das Semantikmodell bei Erfolg.list_objects/get_object_by_id: Abfrage des AML-Applikationsmodells. Liefert alle angelegten Objekte mit Typen, GUIDs und Attributdaten.- Codec-Abstraktion:
TwincatPlcCodec(.TcPOU/.TcDUT/.TcGVL) undStructuredTextCodec(reine.st-Dateien) speisen ein gemeinsames Semantikmodell. - Achsen im AML: Achstypen sind jetzt vollwertige AML-Objekte mit eigenen SystemUnitClasses, verwaltbar über dasselbe CLI/MCP-Interface wie alle anderen Equipment-Typen.
- AML-Schema-Migrationen: Automatische Migration von AmlLibs 1.7 auf 1.8 mit Abwärtskompatibilität.
- Installer-Integration: CLI und MCP-Server sind im Standard-Creator-Installer enthalten.
Creator 1.8 erscheint in Kürze. Fragen oder Interesse an einer Demo des Agenten-Workflows? Melden Sie sich.
Ressourcen aus der Demo
- Zeugwerk Framework Dokumentation: die Live-Dokumentation, die der Agent über
get_docabruft - Tutorial-Quickstart auf GitHub: das Projekt, das der Agent in der Demo implementiert; ein Referenzprojekt, das zeigt, wie eine Zeugwerk Framework-Applikation aufgebaut ist
- Tutorial-Quickstart-Visualization auf GitHub: 3D-Visualisierung desselben Projekts