Cross-vendor Drive onboarding and profile normalization
Every servo drive manufacturer speaks its own dialect: the CiA-402 profile is standard only at its core, while the set of SDO/PDO objects, units, and the specifics of state handling and tuning differ between Inovance, Wecon, Mitsubishi, and Schneider. The classic solution is a closed single-vendor utility for each brand.
Our research is to bring these dialects into a single object model: parse the drive's ESI description, normalize the parameter set, and grow an open library of profiles. The result is not a one-off setup but a cumulative asset — the more drives we onboard, the wider the out-of-the-box coverage.
Status: On the bench: Wecon VD3E, Inovance IS620N, Schneider LXM28E, Mitsubishi MR-J4-TM. Open: automating ESI parsing, extending coverage.
Methodology Servo drive characterization and testing
Drive characteristics are stated by the vendor in the documentation, but real behavior under load — response, positioning accuracy, torque, tendency to resonate — isn't visible on paper, and there is no unified, comparable methodology across brands.
We are developing characterization methodologies for drives and servo motors and building a benchmark dataset from the results. This is both engineering value (objective drive selection for a task) and an R&D outcome (data + methodology).
Status: Methodologies in development. Full characterization under load requires a loaded bench with an accuracy passport.
Digital twin Object model of a machine on top of a digital twin
Today, configuring a drive means manually digging through registers and SDOs for each brand. That's a barrier: fieldbus expertise sits with a narrow circle of specialists, not a shop-floor engineer or integrator.
The research idea is to move configuration up to the object level: the operator works with concepts like "motor — gearbox — axis — load" as objects over a 3D twin, while the system synthesizes the low-level cross-vendor configuration from the model. This lowers the "comprehensibility tax" of EtherCAT/servo.
Status: Part of it exists (SDO/PDO normalization + 3D twin). A full object model of the mechanism is a research direction.
Automation on HAL Programmable automation logic without a classic PLC
Classic automation relies on closed PLCs with ladder logic (IEC-61131): a separate controller, its own environment, vendor lock-in. We build automation logic differently — via HAL, the low-level real-time layer at the core of LinuxCNC, where automation nodes (axes, drives, I/O, actuators) are linked by virtual connections within the same deterministic loop as motion.
A node declares its needs and methods (task-API), and the platform wires them together in HAL — the local Linux box becomes both the logic executor and the API server. This gives programmable, observable, and versionable automation without a zoo of controllers and without a separate proprietary PLC.
Status: HAL orchestration and node task-APIs work on the bench. A full event graph of actuators and a catalog of automation nodes are in development.
Orchestration Machine composition and remote programming
A vendor's local single-drive utility and a closed PLC don't give you the main thing — combining several multi-brand EtherCAT drives into one coordinated machine that can be programmed and observed remotely.
We are researching software-defined composition (several servos → a machine), config-as-code with a passport for the whole assembly, and remote authoring with a local execution loop. The real-time loop always stays on the local Linux box; cloud/edge is for authoring and observability.
Status: A single coordinated machine is demonstrable on the bench (TRL 5-6). Production lines are a direction for further development.
