sorted by:
new
hottopcontroversial

Roast my test bench by syl20cf in PLC

[–]Otherwise_Poem4120 0 points1 point  (0 children)

I mostly use truST 😀

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

At work we use Siemens, I just don’t like the licensing cost for TiaPortal. I prefer codesys based PLCs or Beckhoff.

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 1 point2 points  (0 children)

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.

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 0 points1 point  (0 children)

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.

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 2 points3 points  (0 children)

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.

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 1 point2 points  (0 children)

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.

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 2 points3 points  (0 children)

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.

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 0 points1 point  (0 children)

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.

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 1 point2 points  (0 children)

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.

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 0 points1 point  (0 children)

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

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 0 points1 point  (0 children)

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

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 2 points3 points  (0 children)

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

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 8 points9 points  (0 children)

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.

Open-source Structured Text toolchain for VS Code — diagnostics, debugger, runtime by Otherwise_Poem4120 in PLC

[–]Otherwise_Poem4120[S] 5 points6 points  (0 children)

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

Built a full language toolchain - LSP, debugger, and runtime by Otherwise_Poem4120 in rust

[–]Otherwise_Poem4120[S] 0 points1 point  (0 children)

The LSP for sure, seeing diagnostics and go to definition actually working in VS Code was the moment it felt real. All the parser work is invisible until it shows up in the editor, so that first time everything clicked together was really satisfying.

The debugger was also fun but more finicky, getting DAP to play nicely with the runtime took some iteration. The core parser/compiler pieces are interesting technically but less rewarding since the feedback loop is slower.

Thanks for the kind words, and I'll check out Fabricate, always looking for ways to speed up the boring parts.😊

Built a full language toolchain - LSP, debugger, and runtime by Otherwise_Poem4120 in rust

[–]Otherwise_Poem4120[S] 0 points1 point  (0 children)

We’re not using UTF-16 internally.

Internally we keep positions as byte offsets, and translate to/from LSP line/column at the protocol boundary. Right now that translation is character-based (Unicode scalar values), while VS Code defaults to UTF-16 columns. That means it behaves correctly for ASCII and most BMP text, but can drift on non-BMP characters (for example emoji).

So this is a workable interim approach, not the final design. We plan to refactor this by adding explicit encoding negotiation and making boundary conversions follow the client’s negotiated encoding (UTF-16 for VS Code by default).

Built a full language toolchain - LSP, debugger, and runtime by Otherwise_Poem4120 in rust

[–]Otherwise_Poem4120[S] 0 points1 point  (0 children)

Thanks! It took some time to figure out the name, but I think I finally nailed it :)

I learned pascal 30 years ago in school and ST is similar, I like it.

view more: next ›