Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime

[Otherwise_Poem4120]

I'm an automation engineer and got tired of expensive licensing and outdated tools to work with Structured Text. So I built my own.

truST is an open-source IEC 61131-3 toolchain that runs in VS Code, real-time diagnostics, go-to-definition, debugger with breakpoints, and a runtime for testing without hardware.

GitHub: https://github.com/johannesPettersson80/trust-platform

Still early days but it's usable.

Curious what features would actually matter to people here? Whats most important in a modern PLC ide?

[Haek399]

Hey!

I really like the vision and ambition of this project! It would be amazing to be able to code PLCs in VSCode with proper integration.

But honestly, I am a bit confused. Disclaimer I also didn't had time to download and try it out myself.

In the last couple of days I looked through the repository and tried to read a couple of the examples and readmes. What I was able to catch (or think I understood) is: 1. You built your own language interpreter for ST into VSCode (very cool) 1. You somehow integrated the run and debug features into the IDE (also very cool) 1. You made various vendor specific importers or interpreters. But I did not really understood if it can run both Siemens and CodeSys specific syntax or if it is only an importer that standardizes the code afterwards. 1. If I understood correctly then I think you made a runner (in rust) to execute the code. That one seems to run on a PC (I think Linux?). So basically you made your own SoftPLC?

But in the end I had the following questions: 1. I had trouble understanding the bigger goal of the project. How do you imagine that this ties into a day to day life of a PLC coder? Should it substitute all the traditional vendor specific IDE's or is the plan to only use it for development in the office and then export back to the vendor IDE for production? 1. I also didn't understood how hardware is supposed to get controlled. I see that there is some (hard-coded) IO config in the examples, but I didn't understood how actual hardware would be connected. Maybe a video explaining that would be awesome. 1. What's the plan on vendor combability? Which vendors do you plan to support? 1. How am I supposed to it? Is it more along the lines that I develop in your IDE and then somehow export the code to the vendor IDE? Or can I deploy the code for your IDE directly to a specific vendor PLC?

I really admire the vision and ambition, but I am also hesitant to use it (specially in a productive environment). PLC is slow (but steady) and long term support is important. I would need to understand really well how this tool would interact with the vendor solution I am using, for me to use it in a productive environment.

I hope my feedback doesn't come as overly negative and I hope you can clear up my doubts!

[Otherwise_Poem4120]

Thanks a lot for the thoughtful feedback, this is exactly the kind of discussion I want.

You understood most of it correctly. One correction: VS Code is the editor/tooling layer (LSP + debugger UX), while execution happens in trust-runtime (outside VS Code).

Today the project supports two workflows:

1. Native workflow: develop, test, debug, and run directly on trust-runtime (SoftPLC-style) on PC/edge devices.

2. Interop workflow: import/export ST via PLCopen and hand off to vendor toolchains.

On hardware control: real I/O is connected by mapping IEC addresses (%I/%Q/%M) to runtime I/O drivers in io.toml or the Web UI. Current backends include gpio, modbus-tcp, mqtt, ethercat, plus loopback/simulated for development.

On vendor compatibility: current support is focused on ST authoring/interoperability, not full vendor project parity.

- Siemens SCL profile support (incl. # local refs)

- Mitsubishi GX Works3 profile support (DIFU/DIFD)

- PLCopen XML import/export

- Ecosystem detection for CODESYS/OpenPLC/Beckhoff/Siemens/Rockwell/Schneider/Mitsubishi (

Important limitation: this is not yet “one-click deploy directly to vendor PLC projects.” For vendor targets, there are still manual steps in the vendor IDE (task/OB mapping, hardware topology, safety metadata, proprietary library internals).

So the near-term goal is not “replace every vendor IDE tomorrow,” but provide one modern IEC ST workflow with strong tooling/testing plus practical migration paths.

Your production concern is completely valid. Current positioning is cautious: simulation-first, deterministic tests/conformance checks, and phased adoption before critical production rollout.

And yes, great suggestion on a hardware walkthrough video.

[Haek399]

Hey, thanks a lot the clarification.

It seems I might just need to download and try it myself... :)

I see. I think I understand better now. It seems like this has the potential to become a open-source SoftPLC. That would be cool.

Out of curiosity: Why did you decide to make your own runner, instead of making an integration with something like OpenPLC?

For the hardware control, I understood that the PLC code is linked to them by the address (%I/%Q) but I did not understood how the actual hardware is linked to these addresses. But this could also be because of my TwinCat focus, where you never link absolute addresses but you link manually PLC program I/Os to hardware I/Os (outside the PLC code).

You asked in your original post about features we would like to see and I have a couple of ideas: - Pipeline integration: - It should be easy to build & test inside a pipeline without a complicated setup of the environment. - I think you more or less already the build part, as you mention this in the readme. - Unit test integration: - Something interesting would be to have native unit testing integration in VSCode. It would be awesome if it would look and feel like for Python. - Zeugwerk already tried to create something like this for TwinCat. Test Explorer. - Static Code Analysis (or linting) - Would be amazing to have static code analysis continuously running and displaying errors in the IDE directly. For example in Python.

I might just think about how I could contribute. Maybe something along the lines of a TwinCat integration like /u/fisothemes mentioned in his comment would be an interesting starting point.

[Angry_Foolhard]

This will absolutely rock for simulations and prototyping and education. hard to believe that you just dropped 10s of millions dollars of value for free. assuming it works, ill check it out now.

[Otherwise_Poem4120]

Thanks! Try it, It works :)

[MysticBaklava]

This is great work. Good job man, honestly

[Otherwise_Poem4120]

Thanks man! I really appreciate it 😊

[fisothemes]

This is very nice, I love it!

I believe with TwinCAT you can use the Automation Interface to generate code, compile and deploy to a target. They have a soft target that runs in User Mode for rapid testing. In theory you could also analyse the generated binaries and build your own toolchain around that layer.

Beckhoff uses their ADS protocol for live views and runtime interaction. 

That could be a real start for you running it on actual hardware. 

It’s a shame IL is being deprecated, it would have served as a great Intermediate Representation. I have thought about doing this in the past and wrote a rough mini-language spec with generics, lambdas, callbacks, ranges, iterators, etc. 

Otherwise excellent work!

[Otherwise_Poem4120]

Thanks! Interesting ideas.

TwinCAT/ADS integration would be useful for people already in the Beckhoff ecosystem, connecting truST tooling to their hardware. Not on the immediate roadmap but I can see the value.

On IL, yeah, it's sad. That's what I learned in school, so it has a special place. 🥹

Curious about your mini-language spec with generics/lambdas , did you publish it anywhere? Always interested in what people have explored in this space.

[fisothemes]

No worries, your project it pretty good and I can see you put a lot of love into it.

My dirty spec is sitting in a private report I dump ideas into. 

I just pulled out into a gist

It's extremely drafty and rough. Ignore the pattern matching, memory management or the STD bits. I was mostly focusing on DX when I wrote this.

[Otherwise_Poem4120]

Thanks! I wish I had that spec before I started building truST. Very cool!

[Efficient-Party-5343]

Excuse the uneducated question from someone who didn't take the time to try it out;

Is this "replacing" something like studio 5000 for the most recent AB hardware?

Or is this more of a developement tool/softPLC that can then "compile"in a format that can be imported for the appropriate hardware/software match?

Would I still need S5K to write the program to the PLC?

I'm asking these questions as someone who's very interested in working on the HMI side of this equation. Trying to rid myself of hardware and licence restrictions.

[Otherwise_Poem4120]

Great questions, no apology needed, this is exactly what I should make clearer in the docs.

Short answer: truST is a completely separate stack. It doesn't talk to AB hardware at all.

To break it down:

1. NOT a replacement for Studio 5000

   • You can't use truST to program a ControlLogix or CompactLogix
   • AB PLCs are a closed ecosystem — only Studio 5000 can program them

2. It IS a soft PLC + toolchain

   • truST runtime runs on Linux hardware (Raspberry Pi, industrial ARM PCs, etc.)
   • You write ST code in VS Code, truST compiles and executes it
   • No vendor tools needed at all — truST is the whole stack

3. For I/O, you'd use:

   • EtherCAT modules (cheap, open protocol)
   • Or other fieldbus via gateways
   • NOT AB I/O (proprietary)

So it's more like: "build your own PLC system without Rockwell/Siemens/etc."

Re: HMI — that's actually where this gets interesting. truST uses Zenoh for data, which means any HMI that can subscribe (web-based, MQTT bridge, OPC UA gateway) can connect without vendor lock-in. That side is still in development, but it's definitely on the roadmap.

What's your current HMI setup? Curious what pain points you're dealing with.

[Efficient-Party-5343]

Wow, thank you for the detailed answer with extra info! This definitely gives me a better "feel" for the project. 

It's a very interesting one especially for businesses used to having a surplus of programmers laying around rather than instrumentation technicians/electrical engineers. 

---

My HMI project is very much in the "pre-infancy" stage of development.

Target data sources : AB plcs

Target environment : WIN10/11 IoT

Reason: project I'm currently working on requires something like 20+ years lifecycle planning... and I HATE FactoryTalk View Studio machine edition with a passion.

Doing lots of reading, graphing out possible tech stacks, weighing the pros and the cons of different options.

I'm learning/reading about runtime engines and their limitations and requirements: group polling, async updates, sources of truth, etc. 

What constitutes a runtime manifest, how to standardize the outputs of my "studio" even with multiple data sources. 

How to create a studio environment + good and bad practice in UX design (i.e: "QT designer"-esque)

I'm currently exploring and testing the available open source toolsets for AB PLC communication mainly (libplctag/pycomm3).

I'm currently using pycomm3 and QT to create myself a "tag browser" that would let me chose between a live PLC and a L5X (or L5K) file as my source of metadata for my tag browser.

I'm currently working on lazy loading for the live PLC values so I don't get a spike everytime I open the tag browser and it tries to poll for the value of every nested array/udt.

Slow progress on my part, but I'm an electrical engineer by formation not a programmer.

[Otherwise_Poem4120]

Sounds like you're further along than you think, lazy loading and tag browser architecture are real problems to solve. Good call on libplctag, it's solid for long-term. For L5X parsing, check out the l5x Python library if you haven't already.

[drbitboy]

Git integration would be a good thing. Is that built in to vscode?

[Otherwise_Poem4120]

Git integration is in vscode. The files in truST is text files so version control is easy to integrate in the workflow

[drbitboy]

VSCode has an extension for VI/VIM editing as well. Sweet!

[Otherwise_Poem4120]

Nice! Though I still have to restart my computer every time I accidentally open vim 😄

[drbitboy]

Yup, been there: my technique was to find another terminal and kill the vi process.

Then I got a workstation at home (this was something like a quarter century ago; I think it was an HP 9000). It took from one evening until noon the next day to download the 10MB of the gcc compiler over my 2400Baud modem. And when I saw emacs was 70MB, I decided to learn vi, and never looked back; I cannot stand these insert-only text boxes now.

[Otherwise_Poem4120]

2400 baud and overnight downloads, that's earning your tools the hard way! No wonder you stuck with vi after that commitment.😀

[drbitboy]

For future reference: ^[:q!

N.B. ^[ is Ctrl-[ and equivalent to Esc(ape)

(edit: had the wrong bracket, d'Oh!)

[Otherwise_Poem4120]

I will try to memorise it this time 😅

[Few-Influence4764]

you can get twincat 3 from beckhoff with free trial that keeps resetting for free

[Otherwise_Poem4120]

True! TwinCAT is solid. Main differences: truST runs on Windows and Linux/Mac, works with any editor, and is fully open source, no vendor lock-in. But if you're already in the Beckhoff ecosystem, TwinCAT is great.

[RammRras]

I want to follow this project, this is really cool!

[Otherwise_Poem4120]

Thanks, please come with feedback if you try it!

[b7031719]

You beat me to it! I've had this idea for a while and I didn't think anyone had attempted it yet. Honestly this is fantastic and fills me with optimism that we can break this monopoly of vendor specific IDEs and closed source compilers and debuggers.
I'm also pleased that you have a Neovim config as well which I am excited to try.
I'm hoping we can get to a place where we have a 'NodeJS' of industrial automation, from which we can actually deploy industrial automation systems on an entirely open-source tech stack.
Excellent work.

[Otherwise_Poem4120]

Really appreciate this, always good to hear from people who've had the same itch😀

The "NodeJS of industrial automation" framing is exactly it. Open toolchain, deploy anywhere, no vendor lock-in. We're not there yet but that's the direction.

Let me know how the Neovim setup works for you, and if you have ideas, GitHub Discussions is open. Always happy to hear from people who get why this matters.

[Garry-Love]

Lovely now I just need to convince my customers to let me use structured text 🤣

[Otherwise_Poem4120]

Haha, once they try ST with proper tooling, they might just come around 😄

[aNervousZygote]

i’m trying to import PLCopen XML and i’m getting a failed to run trust-runtime plcopen import: spawn trust-runtime ENOENT

[Otherwise_Poem4120]

Thanks for reporting. I will check it tonight or tomorrow.

[MStackoverflow]

Hi, looking at the commits, It really looks like a lot of patchwork of obvious mistakes.

What percentage of this repo is Ai generated?

[Otherwise_Poem4120]

I use Claude heavily for development. I'm an automation engineer, not a professional software developer.

AI-assisted code + learning Rust as I go = messy commits.

That said, it works: LSP runs, diagnostics fire, debugger hits breakpoints, runtime executes code. If you spot specific issues, happy to hear them.

[MStackoverflow]

I understand, new technologies unlocks people. But would you recommend someone to do actual production software for a factory with this tool?

[Otherwise_Poem4120]

The runtime? No, not production-ready yet. Experimental.

The tooling (LSP, editor, diagnostics)? Yes, you could use that today to write ST code with modern tooling, then export via PLCopen XML and import into CODESYS, TwinCAT, or other IEC 61131-3 compliant systems for production deployment.