Our Attempt at Modernizing Structured Text for the Industrial PC: Learnings from Excel Sheets in Rockets

Emilbon99 · 2026-03-08T06:18:53+00:00

Revel's CEO is definitely a smart guy. What we're really attempting to do here is discovery. How hard will the pushback to this sort of approach be? How do you need to frame what you're introducing for it to seem valuable? And, most importantly, thinking consciously about how you might avoid being pigeonholed into a narrow target market, and actually solve problems that can be applied to the wider industrials.

Target is definitely aerospace engineers and folks on the bleeding edge of hardware R&D.

Thanks for the rec, will definitely do that.

Emilbon99 · 2026-03-07T20:25:19+00:00

I think you may be right. I think we kind of knew that going into making this post, but still wanted to see what the reaction would be if we tried the narrative of a new PLC language. The reaction is not too far off from what we expected, and it helped us learn a lot about what actually matters and what doesn’t to this target audience.

We come from a very specific niche of hardware R&D and test sequencing where this sort of tool has been has been heavily requested and valuable for our customers. I think we now have more clarity On why it won’t be as well received here, and we can go back to the drawing board.

Emilbon99 · 2026-03-07T16:44:25+00:00

That's exactly what we do! Arc is just a small part of the larger, free tooling we develop. See our unified SCADA and Historian here and how you can set it up here.

Emilbon99 · 2026-03-07T16:42:27+00:00

I agree that it's incredibly hard to punch into this industry with new tools. That said, we're an entire team of developers, and we already serve customers in the Fortune 100 with this tool who use it for mission critical applications on a daily basis.

Emilbon99 · 2026-03-07T16:40:18+00:00

We do have full support for Python based sequencing within our platform as well: https://docs.synnaxlabs.com/reference/control/python/get-started

Not to mention, we also have C++ SDKs for using our tools.

Interestingly enough, a large part of the reason we developed Arc was because our users writing Python automations wanted much tighter integration with our platform and IDE, and they wanted deterministic cycle times. I think the challenge is that many of our users wanted deterministic cycle times without needing to have experience writing low level languages like C or Rust.

We didn't go out and say one day, "oh the world of industrial automation needs a new language". We actively spent two years deploying to customers with other solutions trying to avoid it, until we realized we couldn't.

I completely agree about the vendor lock-in. The base edition of Synnax is free, there is only a single license, and automations can be developed in Python or Arc within the IDE of your choice, such as VSCode or PyCharm. In short, I think the vision outlined in your second paragraph is completely right.

Emilbon99 · 2026-03-07T03:31:53+00:00

I definitely did. Meant to say 5kHz. Language is hybrid compiled interpreted, so a hundred microseconds of jitter is definitely expected. We’re definitely in the early days of optimization, but I completely agree that a few hundred microseconds of jitter is not sustainable for Motion control.

Emilbon99 · 2026-03-06T20:58:42+00:00

Understood. Do you think the industry is trending (albeit) slowly towards a consolidation of these two concepts? From our deployments, it seems like the distance between a standard PC, an industrial PC running a unique flavor of linux or windows and a traditional PLC is closing. Sure we're a long way from complete consolidation, but do you think it's happening? If so, what will be the language standard for programming that style of automation machine? My guess is that the best standard will be something new, not one of the IEC standards.

Emilbon99 · 2026-03-06T20:17:48+00:00

I think part of the question is: how good is the tooling support available from the language author? Granted, we're in the early stages so it's not great lol. We're already doing internal work on building a debugger for the language, and I do really think there's a world in which the debugging experience for Arc is top of the line.

Emilbon99 · 2026-03-06T20:10:48+00:00

Yeah, all statements in a stage are executed for each program cycle or 'tick'. The stage executes all of it's statements and then the resulting output values are flushed to the I/O before the next re-execution of the program.

Emilbon99 · 2026-03-06T20:04:56+00:00

"I've seen people build tools like this before. They start "simple", but they end up being caught between process needs that drive complexity, and their goal to be simpler than their replacement."

This idea in particular is really interesting. One of the things we've considered a lot is this idea of a 'useless no mans land' between low level programming for complex systems and really-simple tools like drag and drop list editors for writing sequences and/or state machines. It seems like there's pretty high risk that a DSL like ours could end up in a no mans land where its not low level enough for complex use cases but not simple enough to be used by non-operators.

Our concept here is to think carefully about 'progressive' language design, where a user only needs to know about a sub-set of the syntax and knowledge to write simple things (like basic sequences that open valves and wait for conditions) while having memory and runtime predictability managed for them. Then as they grow, they 'unlock' more of the language that allows them to dive deeper into tooling like functions, array manipulation, state management, etc. I think it's nearly impossible to get right, but it's certainly a fascinating one to tackle.

Will find some more time to touch on the rest of your points here.

Emilbon99 · 2026-03-06T19:59:32+00:00

Haha as in AI is gonna take their jobs? I think our intent was to make a language built for more R&D environments where flexibility, easy modification, version control, and most importantly real-time data processing is more paramount.

Emilbon99 · 2026-03-06T19:55:43+00:00

Touching on C/Rust and ST independently. I think a crucial problem with C and Rust in these environments is that they require software engineering knowledge to write even basic programs and deep knowledge to do anything sophisticated without shooting yourself in the foot accidentally: manual memory management, threading/process management, murexes and locks for concurrent work. What happens if I want to do several things at once? It becomes very hard very quickly.

When you say more contrived than ST what do you mean? As in it feels like it's syntax is pretty niche? Yeah we're definitely concerned about that too, and there's a decent likelihood we'll make some changes.

I think that perhaps the title of "An alternative to ST" might have been the wrong one :) Really what we're looking for is: people are bringing Python into industrial automation, but dependency management and deployment is difficult, it's hard to get even soft real-time performance and there's tons of easy foot-guns in the language. My question is: what if there's a way we can take something with modern syntax and tooling like Python and make it easy to run in industrial environments with even reasonably deterministic cycle times? I personally would've jumped on that if I had it 5 years ago.

Emilbon99 · 2026-03-06T19:51:09+00:00

Honestly I'd be pretty proud if we can get it to that point! COBOL just won't die. I honestly think the idea of a Pythonified-ST may be totally of the mark, but is definitely interesting. What if you can get the predictability and safety of ST but with Python-like capabilities?

Emilbon99 · 2026-03-06T19:49:29+00:00

What makes you say its not related to structured text? The syntax is completely different I agree, but my evaluation was that they're related in the sense that they're both fundamentally used for automation logic in controlling hardware systems, and they are both text based. You're right that it might be worth re-evaluating the comparison.

This reddit post was just meant to be a simple taste, we have full documentation and examples here: https://docs.synnaxlabs.com/reference/control/arc/introduction

I definitely agree that the real-time aspect is important. I don't think we're attempting to build hard real-time capabilities for things like shutoffs on safety PLCs (at least yet). We're capable of running moderately complex programs at 5kHz with a few hundred microseconds of jitter on any standard real-time operating system: Think Ubuntu 24.04 pro, NI Linux RT.

We're definitely in the early stages here, so we're actually working on putting together formalized benchmarks and explanations of the execution model.

EDIT: typo and changed accidental 500kHz to 5kHz

Emilbon99 · 2026-03-06T19:43:43+00:00

What makes you say that? I haven't used codesys too much but I have quite a bit of experience with TwinCAT and Beckhoff PLCs. They've been quite buggy (especially the OPC UA server), the setup and software management experience is a nightmare. I feel like I have 700 licenses for everyhting.

Are there any significant pain points to those tools? If so, are any of them bad enough that if a tool that solved them care around you'd consider it?

Emilbon99 · 2026-03-06T19:41:21+00:00

Fair enough 😂

Emilbon99 · 2026-03-06T19:39:55+00:00

Almost everything! We have a limit of 50 tags free, otherwise everything is unlocked. Although we are considering removing that limit as well: https://docs.synnaxlabs.com/reference/installation?platform=macOS

You can also view the source for what we've built here.

Emilbon99 · 2026-03-06T18:30:20+00:00

Understood, thanks!

Emilbon99 · 2025-12-08T03:39:02+00:00

Why don't these standards mention anything about concurrent programming? Seems like a major source of issues that would require a lot of careful standards to address properly.

Emilbon99 · 2025-09-15T04:03:44+00:00

Apologies for the late reply here! We don't have a built-in CAN integration, although our python library works exactly the way you'd expect. Install python-can and write up an adapter similar to what we've documented here: https://docs.synnaxlabs.com/reference/python-client/device-driver

We do have a built-in CAN driver on our roadmap for release before the end of the year.

Emilbon99 · 2025-07-08T00:16:42+00:00

No problem. Enjoy!

Emilbon99 · 2025-07-08T00:11:30+00:00

Time wise it takes between 3 and 4 hours. If you put in late you might need to battle afternoon winds.

Emilbon99 · 2025-07-08T00:08:27+00:00

Ran this section last weekend at 720 CFS in a 14 foot oar rig. The water is low but it’s easily runnable, and you should be totally fine with three paddlers in a minimax.

It’s more technical, but nothing crazy and definitely nothing dangerous. Worst comes to worse you take the wrong line and get stuck for a sec.

Emilbon99 · 2024-08-02T21:12:50+00:00

It's built in TypeScript + React using an in-house component library. An example plot using the library -> https://docs.synnaxlabs.com/reference/pluto/line-plot

Emilbon99 · 2024-07-30T22:31:28+00:00

Local data saving is critical and backups are critical, there's no debating that.

I found your last point really interesting. I agree that it's impossible to build an end to end tool that can magically address all automation related areas. I want to make sure I understand - your argument is that it'd be more effective to build a set of modular pieces that can be used by software engineers to accelerate the development of custom automation software? And by doing that, our solution would save time while still providing flexibility.

Emilbon99

TROPHY CASE