Treadlight Technologies builds and modernizes the software that runs industrial machines and robots. We cover system design, application software, operator screens, and the firmware on the equipment itself.
Schedule a callCapabilities
We decide how the pieces fit together before anyone writes code — what runs where, what happens when something fails, and how the parts talk to each other. These are the decisions that get expensive to revisit once a line is running.
C++ is everywhere in industrial software, and an enormous amount of valuable working code is written in it. But it was designed for equipment that was never going to be on a network, and its sharp edges — manual memory management, undefined behavior, data races — are no longer the price of performance: Rust is in the same performance class and rules that whole category out at compile time, with modern tooling and dependency management around it. So rather than paying for that maintenance year after year, we migrate — incrementally, not as a rewrite. Rust and C++ run side by side in the same product, so the highest-risk parts move first and the rest keeps working, and you get the memory-safety benefit where it counts without pausing delivery. We are fluent in C++ and will happily maintain what you already have in the meantime.
Requirements through commissioning, with the discipline the rest of software engineering takes for granted: version control, code review, automated testing. One definition of the data, typed end to end — the same types checked by the compiler in Rust on the machine and in TypeScript in the browser, so an operator screen cannot quietly disagree with the controller it is driving. Mismatches surface at build time rather than during commissioning, which is where they get expensive. Python sits alongside both for test rigs, tooling and data work.
High-level logic belongs on a PC, where it can be tested automatically, changed quickly and updated in the field. Timing-critical and safety-critical logic belongs on a microcontroller or PLC, where behavior is predictable. We draw that line deliberately and build both sides of it.
Web-based HMIs by default. The same interface runs on the panel at the machine, on a tablet out on the floor, and on a laptop off site — so a supervisor can monitor, and where it is appropriate control, without walking the line. Standard web protocols and frameworks — SvelteKit, in our case — keep both the first build and the next decade of changes cheaper than the proprietary, per-seat toolkits much of the industry still runs on, many of which were designed in the 1990s. Qt stays in the toolbox for devices that cannot run a browser, and for safety-related functions that have to live on the panel itself rather than at the far end of a network.
Whether it is a PLC on the other side of OPC UA, Modbus or MQTT, or a robot behind a REST API and a websocket, we pull the logic up out of the device. What stays behind is only what genuinely has to live there — which means far fewer of the fiddly, error-prone updates that this equipment handles worst.
We build on Linux, real-time or not. A mainline kernel with PREEMPT_RT gives deterministic timing on the same machine that runs everything else, so hard real-time no longer requires a separate proprietary runtime. Everywhere else, ordinary Linux means a long security-update life, hardware you can buy from anyone, and tooling that every engineer you hire already knows.
A software fix for equipment in the field should not need a van and a laptop. We build update paths that are staged, verified and reversible — an image either applies completely or rolls back, so a bad update never strands a machine on a customer site. Driven from wherever suits you: a cloud service, your own servers, or an engineer with a USB stick.
The clearest win today is in how the software gets built. AI tooling shortens the loop between a change and a tested, reviewed result, and that is time you are otherwise paying for. Beyond development, a plant floor produces a great deal of data nobody currently reads — cycle-time optimization, quality inspection and anomaly detection are real openings, and we would rather scope one against your data than promise you a number up front.
Approach
Too much industrial software is still developed the way it was thirty years ago: on the machine, in a vendor IDE, by one person who has to be standing next to it. That is the part we change first.
Linux PC
Tested automatically. Changed in an afternoon. Updated in the field.
Microcontroller or PLC
Predictable timing. Behavior you can certify.
Linux PC
Operator interface
Application logic
Tested automatically. Changed in an afternoon. Updated in the field.
Microcontroller or PLC
Predictable timing. Behavior you can certify.
We model the machine — its I/O, its motion, the devices it talks to — and develop against that model. Mocks stand in for equipment nobody has ordered yet, and where the timing or the physics genuinely matter we validate the model against real hardware and keep it honest. Most of the software can be finished months before a cell is built, so when the equipment does arrive, commissioning is about the parts of reality the model got wrong rather than about writing the software.
The same simulation the developers work against runs on a laptop in front of a customer. Your team can walk someone through the operator screens and the sequence of a machine that does not physically exist yet — a new product, a new option, the next iteration of a line already running — and bring the changes back while they are still cheap to make, before anything has been bought.
Developing on live equipment means slow cycles, limited access, and a queue of other people who also need the machine. Moving the work to a simulated backend means changes get tested in seconds, and tested automatically.
Structured logging turns "it stopped again on second shift" into a timestamped sequence of events. A fault at a customer site can be traced, reproduced on a desk, fixed, and covered by a regression test before anyone else ever sees it.
PC-based control runs on hardware you can buy anywhere, with an open toolchain. No per-seat development license, no per-runtime license, and no waiting on a vendor to support the thing you need to do next.
On a PLC, a change means somebody on site with a laptop and the right version of a vendor IDE. On a PC-based system it means the release process the rest of the software industry already uses — which is what makes updating a machine remotely practical at all, rather than a thing you hope never to need.
Why Rust
Rust is a systems language with one unusual property: an entire category of bug is impossible to write. On a machine that has to run for a decade, that changes what the maintenance years look like.
Memory bugs are the ones that stop a line at three in the morning and then cannot be reproduced afterwards. Rust rejects them at compile time, so they never leave a developer machine, let alone reach a customer site.
Industrial equipment sits on networks now. — a figure both Microsoft and Google have published from their own products. Rust removes that whole category by construction.
A strong type system means the compiler tells you what a change broke, rather than a technician discovering it on site. Bringing a new engineer onto an unfamiliar Rust codebase is a much shorter exercise than onto an unfamiliar C++ one.
Rust runs in the same performance class as C++, with no garbage collector and no unpredictable pauses. It is a real option for hard real-time work, not a trade-off you accept for the memory safety.
Contact
A little about your company, your product, or what you would like to build — plus your availability for a call — is enough to start.