Damit Ihr Agent
TwinCAT nicht mehr errät.

Unter Windows setzen Sie Ihren Download-Token und führen einen PowerShell-Befehl aus. Der installiert plcsense über Scoop und aktiviert bei Bedarf Ihre Lizenz.

$env:PLCSENSE_TOKEN = '<your token>'
irm https://plcsense.com/install.ps1 | iex

Lieber den MCP-Client über npm einrichten? Derselbe PLCSENSE_TOKEN, Node.js 18+, heute Windows x64, und weiterhin eine kommerzielle Lizenz.

$env:PLCSENSE_TOKEN = '<your token>'
npx -y @zeugwerk/plcsense mcp

Download-Token und Lizenzschlüssel gibt es mit dem Early Access dieser Runde, der für neue Anmeldungen geschlossen ist; wenn Sie sich schon angemeldet haben, gehen die Schlüssel gerade laufend raus, Ihrer kann also noch unterwegs sein. Tragen Sie sich für die nächste Runde in die Launch-Liste ein. Das Installationsskript ist reiner Text, Sie können es vor dem Ausführen lesen.

Windows, PowerShell und die TwinCAT-Solution, an der Sie arbeiten wollen. Weder TwinCAT noch XAE müssen installiert sein, damit plcsense Ihr Projekt und dessen Bibliotheken liest. Ist ein lokaler Managed-Libraries-Ordner vorhanden, wird er genutzt, und wenn Ihre Bibliotheken anderswo liegen, können Sie den Pfad umstellen. Der npm-Launcher braucht zusätzlich Node.js 18+.

Cursor, Claude Code, VS Code, Codex und Gemini CLI. Führen Sie den passenden Setup-Befehl in dem Ordner aus, den Sie in Ihrem Agenten öffnen und in dem Ihre TwinCAT-Solution-Dateien liegen: Er schreibt den MCP-Eintrag für diesen Client und eine .Zeugwerk/plcsense.json, in der Sie auf Ihre Dokumentation verweisen können. Nur im Projekt, an Ihrer globalen Agent-Konfiguration ändert sich nichts.

plcsense setup cursor

plcsense setup <client> schreibt .Zeugwerk/plcsense.json einmal, mit jedem Schalter vorhanden und auf seinem Standardwert, damit die Datei selbst zeigt, was sich ändern lässt, statt es im Code zu verstecken. Nichts darin ist geheim, Sie können sie also bedenkenlos zusammen mit der Solution einchecken.

{
  "config_version": 4,
  "managed_libraries": {
    "root": "C:/TwinCAT/3.1/Components/Plc/Managed Libraries/"
  },
  "doc_sites": {
    "ZCore": { "root_template": "https://doc.zeugwerk.dev/{channel}/" },
    "AcmeSealingLib": { "root": "https://docs.acme.example/sealing/1.4/" }
  },
  "beckhoff_infosys": {
    "enabled": true,
    "cache_ttl_hours": 168,
    "crawl_delay_ms": 10,
    "extra_eligible_namespaces": []
  },
  "confluence": {
    "enabled": false,
    "base_url": "https://your-site.atlassian.net/wiki",
    "spaces": [],
    "library_namespaces": {}
  },
  "parser": { "backend": "TreeSitter" },
  "libraries": {
    "transitive_references": true,
    "max_depth": 8,
    "max_libraries": 250,
    "wrapper_hint_names": ["ZPlatform", "ZAux"],
    "hydration_profile": "signatures"
  },
  "validation": {
    "semantic_checks": true,
    "disabled_checks": []
  },
  "workspace": {
    "solutions": []
  }
}

config_version

Stempel des mitgelieferten Presets, keine Produktversion. setup schreibt eine Datei nur neu, wenn ihr Stempel hinter dem aktuellen liegt, und fragt vorher nach, sofern nichts anderes eingestellt ist.

managed_libraries.root

TwinCATs eigener Managed-Libraries-Ordner. Löst standardmäßig bereits %TWINCAT3DIR% auf; nur setzen, wenn Ihre Bibliotheken anderswo liegen.

doc_sites.<Namespace>

Wo die zkdoc-Ausgabe einer Bibliothek liegt, je Namespace, damit get_plc_type_documentation die Version liest, die Ihr Projekt tatsächlich referenziert. root_template löst dafür einen Platzhalter {channel}/{version} auf; root ist eine feste URL für eine Seite, die ihre Doku nicht versioniert.

beckhoff_infosys.*

Standardmäßig an, holt offizielle Beckhoff-Seiten für Beckhoff-Bibliotheken. cache_ttl_hours und crawl_delay_ms sind Cache- und Höflichkeits-Schalter; extra_eligible_namespaces ist ein Notausgang für eine Bibliothek ohne Tc2_/Tc3_-Namen und ohne Herstellerkennung.

confluence.*

Aus, bis Sie enabled setzen. base_url und spaces grenzen die optionale Confluence-Cloud-Anbindung ein; das Token selbst ist eine Umgebungsvariable, nie eine Zeile in dieser Datei.

parser.backend

Standardmäßig TreeSitter; Antlr ist die Ausweich-Engine für die Grammatik.

libraries.*

Wie weit die Bibliotheks-Hydration Referenzen folgt: transitive_references, max_depth und max_libraries begrenzen den Durchlauf; wrapper_hint_names meldet einer Validierungsprüfung Ihre eigene Wrapper-Konvention; hydration_profile ist "signatures" (Standard, ohne Methodenrümpfe) oder "full" (Quell-Bibliotheken behalten auch ihre Rümpfe).

validation.*

semantic_checks schaltet die zusätzlichen Prüfungen ganz ab, wenn eine öfter falsch als richtig liegt; disabled_checks unterdrückt stattdessen nur einen einzelnen Regel-Code.

workspace.solutions

Leer heißt: jede .sln, die direkt in dem geöffneten Ordner liegt, wird gemeinsam als ein Workspace geladen. Zwei Solutions nebeneinander sind eine normale Maschine, kein Fehler. Tragen Sie hier Pfade ein, um auf die Solutions einzugrenzen, an denen Sie gerade arbeiten, oder um eine hinzuzunehmen, die außerhalb des Ordners liegt: nur so sucht plcsense dort überhaupt. Solutions in Unterordnern werden nie von selbst aufgegriffen, ein Repository mit einem Dutzend davon lädt also nicht ein Dutzend Kopien derselben SPS-Projekte.

Das alles funktioniert bereits ohne jede Änderung. doc_sites ist der Abschnitt, den die meisten von Hand anpassen, um plcsense auf die Dokumentation ihrer eigenen Bibliotheken zu zeigen.

Nein. Es gibt kein LSP, keine Inline-Vervollständigung, keine Diagnosen im Editor: plcsense antwortet nur, wenn ein Agent eines seiner MCP-Tools aufruft. Wenn Sie das fragen, haben Sie aber schon das eigentliche Problem gefunden: Agenten raten bei TwinCAT-Code, weil ihnen niemand den fundierten, semantischen Blick auf eine Solution und ihre Bibliotheken gibt, den ein Language Server bei verbreiteten Sprachen liefert. Genau diese Lücke schließt plcsense, als MCP-Tool statt als LSP. Schreiben Sie uns im Formular der Launch-Liste, woran Sie arbeiten: Wer diesen Unterschied kennt, ist den meisten Demo-Anfragen schon voraus.

Nicht bei einer einzeiligen Änderung an einem Funktionsbaustein, den Sie schon kennen und der in der offenen Datei steht. Die Datei zu lesen reicht dort, und ein Agent, der vom Bildschirm rät, wirkt genauso gut.

Sie merken den Unterschied, sobald die Arbeit diese Datei verlässt. Dazu gehören ein paar Zeilen gegen einen anderen Typ derselben Familie, eine Bibliothek, die Sie noch nicht aufgerufen haben, ein Interface mit mehreren Implementierungen, eine Umbenennung über viele POUs oder ein Projekt, das jemand anderes geschrieben hat.

Eine Textsuche oder die .tmc Ihres letzten TwinCAT-Builds kann für Namen, die schon auf dem Symbolbaum dieses Projekts liegen, immer noch korrekt aussehen. Beides findet keine Methode, die nur auf einem anderen Typ existiert, nicht den Rest einer Bibliothek, die Sie noch nicht aufgerufen haben, nicht welche Überschreibung tatsächlich läuft, und keinen einheitlichen Blick über mehrere PLC-Projekte. find_plc_implementations und find_plc_references antworten über den Typ, nicht über den Text.

Der Fehler, den das verhindern soll, ist oft eine Zeile, die nach Structured Text aussieht und nicht kompiliert: Die Methode gibt es, nur nicht auf diesem Typ. Es ist auch eine Umbenennung, die kompiliert und dabei eine Aufrufstelle still übersieht.

Heute nicht: Wir testen auf TwinCAT 3 und unterstützen TwinCAT 3. An der Engine ist allerdings wenig Beckhoff-spezifisch. Sie liest Structured Text nach IEC 61131-3, herstellerspezifisch ist die Schicht, die Projekte findet und Bibliotheken auflöst. Bei einer Toolchain, die ihre Quellen als reine ST-Dateien ablegt, ist genau diese Schicht die ganze Arbeit: Der Code von SIMATIC AX wäre damit weitgehend erreichbar, der Inhalt seiner Paket-Bibliotheken nicht. CODESYS braucht die Quellen als lesbare Dateien, also einen Export statt der binären Projektdatei. Schreiben Sie ins Formular, womit Sie arbeiten: Was nach TwinCAT kommt, ist genau die Art von Frage, die die Pilotphase entscheidet.

Noch nicht. Die Analyse selbst braucht kein Windows, aber Windows ist die einzige Plattform, für die wir heute ein Paket ausliefern, und das ist für Early Access die ehrliche Antwort. Schreiben Sie es ins Formular, wenn eine andere Plattform der Grund ist, weshalb Sie es nicht einsetzen können: genau das soll die Pilotphase klären.

Scoop: scoop update plcsense, oder Installer erneut ausführen. npm: der nächste npx -y @zeugwerk/plcsense holt die veröffentlichte Version. Rechnen Sie im Early Access damit, häufig zu aktualisieren.

scoop update
scoop update plcsense

Öffnen Sie Ihre eigene Solution und fragen Sie nach einer Bibliothek, auf die Sie sich verlassen, die Sie aber noch nicht aufgerufen haben. Genau das deckt eine Textsuche oder die .tmc Ihres letzten Builds nicht ab, weil der Rest dieser Bibliothek nie auf dem Symbolbaum dieses Projekts gelandet ist.

"Wie rufe ich FB_SealHead aus AcmeSealingLib auf? Welche Methoden und Parameter hat es?"
"Welche Typen in diesem Projekt implementieren [ein Interface aus einer Bibliothek, die wir nutzen]?"
"Was sind die gültigen Werte von E_SealPhase in der referenzierten Version von AcmeSealingLib?"
"Wo wird ST_SealDose in dieser Solution verwendet?"
"Validiere dieses Projekt und behebe, was dabei herauskommt."

Das liegt mit Absicht nahe an der Demo-Ausgabe oben auf dieser Seite: Dieselben Tools beantworten das auf Ihrer eigenen Solution.

Der Early Access dieser Runde ist für neue Anmeldungen geschlossen, wir verschicken die Lizenzschlüssel dafür gerade laufend, alle in dieser Runde sollten ihren bald haben. Tragen Sie sich in die Launch-Liste ein, wir schreiben, wenn plcsense öffentlich verfügbar ist, oder früher, falls vorher ein Platz frei wird.