Software-defined automation
We move the configuration and control of industrial drives up to the object level. Instead of manually digging through registers for each brand — a single machine model on top of the digital twin, with the system assembling the low-level cross-vendor configuration on its own. An open foundation (LinuxCNC, EtherCAT) plus our proprietary intelligence layer.
Settings live in the twin.
The machine is its mirror.
Axes, spindle, tools, zero points — all in the twin. Configuration is generated from it and pushed to the machine. Import from the bench only seeds the twin — no second source of truth ever appears.
Change it here — the change propagates to the machine. Versioned, backed up, moved to different hardware in minutes.
Receives the config and program, executes the cut, reports state back. No side manual edits bypassing the twin.
Two layers — one product
Assemble the machine from drives → set the tracks → run it. Instead of a zoo of utilities, a closed PLC, and a separate CAM — a single environment, remote and cross-vendor.
Bring up, configure, and coordinate drives into an object model of the machine: kinematics, axes, I/O, equipment profiles. Discovery and tuning.
Set toolpaths, motion, and logic: CAD constructors, CAM, simulation, sending to the machine. This is where the control program is born.
An object model instead of registers
The digital copy isn't a "black box" — it's an explicit construction with described kinematics, axes, drives, and tooling. The operator works with objects (motor — gearbox — axis — load), and the assistant assembles the configuration for them — both the part and the automation logic.
The assistant assembles the part
Accounting for material, the tool catalog, and machine specifics: cutting parameters, machining steps, a control program for your kinematics.
The assistant assembles the logic
Axes, I/O, CiA-402 drives, automation nodes — configuration for the specific machine, not a generic template.
Automation logic without a separate PLC
We don't build automation logic on an external ladder-logic PLC (IEC-61131), but with HAL — the low-level real-time layer at the core of LinuxCNC. Automation nodes (axes, drives, I/O, executors) are linked by virtual connections in the same deterministic loop as motion; complex logic runs as RT modules in C/Python.
A node declares its needs
Each executor declares its methods and what it requires; the platform wires it into HAL. The technologist assigns hardware, not programs the controller.
Linux instead of a controller
A local Linux box is both the logic executor and the API server. No proprietary PLC, no vendor lock-in.
Programmable and versionable
The logic is versioned as code, observed live, and unfolds into an event graph of executors.
EtherCAT only — deliberately
We specialize in EtherCAT with a control loop from 1 kHz — a deliberate focus, not universality for its own sake. A single bus for nodes and axes; other protocols connect through converters into EtherCAT. This matters most on a box where one node drives several machines: mixing protocols there is engineering chaos no one can keep track of, and it breaks determinism and isolation. Order on the shop floor: an open control layer on a local Linux box, monitoring in the cloud or at the edge. The execution loop is always local.
Different brands — one machine
We normalize the CiA-402 dialects of different manufacturers and combine mixed-brand servo drives into one coordinated machine.
A local deterministic loop
Execution runs on a local Linux box with hard real time. The cloud is for authoring and observability, not for closing the loop.
A passport for the whole build
Machine configuration is versioned as code, portable to different hardware, and comes with a passport and an open profile library.
Different brands on one bus
Slave list from a real bench: an Omron coupler, Inovance IS620N, Mitsubishi MR-J4, Wecon VD3E — on one EtherCAT bus, mapped to machine axes.
Autonomous client-server, role-based interface
In progress — a prototype of a fully autonomous client-server solution: the server lives on the local box, thin clients open in a browser from any device on the shop floor. The interface is split by user level — each role sees exactly its own set of functions.
Runs without the cloud
Client and server live on the local box — control and authoring stay available on the shop network even without internet. The cloud is for observability, not for closing the loop.
Server on the box, client in the browser
Thin clients open from any device: the setter's tablet, the process engineer's laptop, a panel by the machine. Nothing to install.
Interface tailored to the user level
Split by access level — process engineer, setter, operator. Each sees its own set of functions and data: nothing extraneous, no risk of touching someone else's.
Where we sit in the automation pyramid
The classic ISA-95 model divides automation into levels. SyncTwin replaces the zoo at the control and supervisory levels with a single software layer on top of EtherCAT, and feeds data upward through an API without replacing MES and ERP.
ERP — enterprise planning
Orders, resources, economics.
MES — manufacturing execution
Work orders, traceability, output.
SCADA — supervisory control and monitoring
Live twin, DRO, scopes, state.
Control — real-time loop
Software-defined layer; drive coordination runs locally. Remotely — commissioning and monitoring only.
Field — drives, I/O, sensors
EtherCAT / CiA-402, a single bus.