Inside the 2ot TwinCAT integration
How the TwinCAT backend, Visual Studio sensor, VSIX packaging and shared test infrastructure fit together as product surfaces.
TwinCAT support in 2ot is broader than a build script. The repository contains a dedicated compiler backend, a Rust integration crate, a VSIX installer, a Visual Studio sensor package and TwinCAT-specific test support. Together they give automation scripts and LLM harnesses an execution and context layer around the TwinCAT engineering environment.
A first-class compiler target
The compile layer has a dedicated TwinCAT backend, while the compiler tree contains TwinCAT-specific lowering and emission code. Target behavior stays behind the same compiler architecture used for the other supported environments rather than leaking into a collection of public helper commands.
A sensor inside the IDE environment
The Visual Studio sensor package tracks the active window and build diagnostics, defines integration payloads and exposes a pipe bridge. It is part of the 2ot TwinCAT integration; internal .NET namespace naming stays in source and does not appear in the product documentation.
- Active-window tracking provides context from the Visual Studio/TwinCAT environment.
- Build-diagnostic tracking gives 2ot a dedicated diagnostic integration point.
- A pipe bridge carries integration payloads between the IDE-side sensor and the surrounding toolchain.
- A dedicated VSIX installer packages the TwinCAT Visual Studio integration.
Verification belongs beside the backend
TwinCAT-specific runner and TcUnit support live in the shared 2ot test infrastructure alongside multi-vendor and runtime-equivalence suites. That keeps the public story focused on compiler behavior, diagnostics and verification instead of internal automation scripts.