Platform2026-09-22
One program, three carriers: tool orientation is set from the part, axis letters are printed by the engine
In motion programs the tool orientation is now described in the part frame — tilt from the normal and azimuth (orient {tilt, turn}) — instead of the axis letters of a particular machine. The carrier letters are printed by the engine from the axis roles in the catalog: a tilting 5-axis head gets B/C directly, a trunnion table gets the same angles with the opposite sign, a robot arm gets inverse kinematics from the tool direction, a welding positioner only a turn. The same weld seam now runs on a tilting head and on a KUKA robot without editing the program text — the first step of the portability matrix "machine breed × effector × program". The table sign is marked as an assumption until verified by a track on virtual axes. Also: the tilting head is printed with the 5axiskins solver and a pivot length from the twin, and preflight judges the work envelope by the maximum stock box including B/C rotation.
Bench2026-09-21
End-to-end scenario against production ran to the end of the program on virtual axes
A real-user scenario executed by one script against cncai.ru and a bench with virtual axes: machine created through the API, LinuxCNC configuration generated from the twin and launched, three joints homed, part zero declared and confirmed by the feedback frame, a cutting program run to the end in 39.9 s — spindle at the commanded speed, motion.in-position, clean LinuxCNC log, torque removed, bench released with no orphans. The path judge compared fact with intent: 99% of samples within the 0.05 mm tolerance, one 0.11 mm outlier at a corner. Analysis showed it was measurement, not the planner: position and program-line pins are read in one dump about 8 ms apart — 0.11 mm at 800 mm/min — and the G64 blend arc lies farther from a single segment than from the corner. The judge now measures distance to the intended line around the segment; tolerance is unchanged, leaving the path is still red. "G61 at corners" was rejected — it would have cured a measurement artifact with the machine program.
Bench2026-09-12
A program ran on real servo drives: five axes, an 83-frame track
A motion program for the robot twin was sent from cncai.ru to the bench and executed on live drives: five servo axes on EtherCAT, six slaves in OP, LinuxCNC interpreter without errors. The fact was taken from three channels, not from the button reply: HAL pins (83 frames at 5 Hz), drive encoders moved on all five axes, a clean LinuxCNC log. Torque was applied only inside the E-STOP reset → home → run step and removed with measured confirmation. First program run on real servos since 26.08; there is still no machine mechanics under the bench axes — TRL 5.
Open source2026-08-25
Our EtherCAT driver for Inovance drives has been accepted upstream in LinuxCNC
Our driver for Inovance servo drives has been accepted into the main branch of the linuxcnc-ethercat project: PR #512 was merged into master on 21 August 2026 by project maintainer Luca Toniolo. Until then the project catalog of supported hardware — 272 devices — contained no Inovance device at all. The driver covers two models, the IS620N and the SV660, in CSP, CSV and CST modes; both are listed as "tested and working", and that status rests on work done on our own bench: three IS620N drives reached OP and moved the axes of a milling machine, and an SV660 ran 30 revolutions forward and back in CSP. The driver shipped in release v1.43.0 on 22 August; the project publishes ready-made .deb packages for Debian 11, 12 and 13, so these drives can be used without building from source and without a third-party fork — on 25 August we verified the official package on our own bench. Our second driver, for Wecon VD3E drives, was merged into master on 24 August and will ship in the next release.
Publication2026-08-10
Second Habr article: the drive answered ACK — what did it actually promise?
A follow-up on our test bench: why an acknowledgement on a fieldbus almost never means what the person reading the log expects it to mean. Between the master and the hardware there are four different kinds of "accepted" — the frame came back, the SDO was acknowledged, the state machine advanced, the shaft actually moved — and each answers only its own narrow question. Trouble starts when the answer of one stage is taken for the answer of another. Every case is real, from the same bench (Inovance IS620N in CSP, a Wecon VD3E drive, an Omron IO coupler, LinuxCNC on top of the IgH master): an SDO error that is printed in successful runs too and cost us a couple of evenings; a mode write that returned ACK yet changed nothing — the command lives in 0x6060 while the fact lives in 0x6061; clearing drive faults over the bus from PREOP, where the ACK arrives regardless of the effect. As in the first article, every figure carries its source — measured on hardware, taken from the datasheet, or an honest "we do not know". The article is in Russian.
Publication2026-08-08
Our article on EtherCAT in LinuxCNC is out on Habr
We published a technical breakdown of the LinuxCNC + EtherCAT stack on Habr: why servo communication over the CiA-402 profile goes, in most installations, through a single small open-source component — cia402.comp — that has neither active forks nor competitors. The article walks the stack layer by layer, from the network card and the IgH master through the bus driver up to LinuxCNC joints, and covers what the documentation leaves out: where the shared profile ends and vendor-specific behaviour begins. It is written from the commissioning of our own test bench: three Inovance IS620N servo drives, a spindle on a Wecon VD3E drive, and discrete IO on an Omron coupler. Every figure carries its source — measured on hardware, taken from the datasheet, or an honest "we do not know". The practical takeaway for anyone who treats EtherCAT as expensive industrial exotica: a working machine is assembled from an ordinary industrial PC, an ordinary network card, an open-source master and mid-range drives — without a single proprietary component. The article is in Russian.
Industry2026-07-29
The digital twin of a machine tool: how our approach differs
We went through three recent publications on the subject — a critical dissection of the term on Habr, the Elsevier review "Digital Twin applications toward Industry 4.0" (2023), and an industry primer. They agree: in most work a digital twin is a layer on top of operating existing equipment (sensors, telemetry, predictive diagnostics, KPIs), while the Elsevier review states plainly that integration between the physical and digital domains remains unsolved. The model describes the machine but controls nothing in it. Our twin runs the other way: CNC and drive configuration is not hand-written but generated from the machine model — axes, kinematics, spindle and tooling become a ready control-system config and reach the equipment in a single operation. The return path is closed too: EtherCAT bus scans and commissioning results feed back into the same model, so no second source of truth exists. By the criteria of that critical Habr piece this is an "instrumental" twin — model-to-hardware fidelity is guaranteed by generation, not by an engineer being careful. The payoff is measured in commissioning, not in the looks of a 3D scene: the whole loop is verified virtually before the drives are ever powered.
Platform2026-07-24
A local web panel on every stand box
Each box now runs its own web interface right on the shop-floor hardware — no cloud required. An operator opens it in a browser from any device on the shop network and sees box status (cores, RT isolation, memory, platform binding and the last server exchange), the list of machine VMs with controls (start / stop / reset / autostart), a network port map, and a remote-support button — a temporary secure channel to a SyncTwin engineer that opens only with explicit consent. The panel works even before the box is bound to the platform and when the internet is down — everything is read from the box itself.
Platform2026-07-22
Public drive parameter catalog and documentation are live
A reference of EtherCAT drive parameters is now open (Wecon VD3E, Inovance IS620N, Schneider LXM28E, Mitsubishi MR-J4-TM — up to 1130 parameters per model, with RO/RW access marking) along with CiA-402 motion profile documentation. The site is available in Russian, English and Chinese.