EtherCAT Platform

A typed EtherCAT master for coordinated motion.

EtherCAT integration too often leaves robotics teams decoding cryptic errors while adapting their software architecture to the master implementation. Tinverse’s EtherCAT master provides a modern, flexible boundary between motion-control software and the EtherCAT network. EtherCAT Platform discovers drives and I/O devices, configures their process data, moves cyclic inputs and outputs, and keeps network state visible to the application. The Rust SDK expresses the EtherCAT operating sequence as types instead of relying on caller convention.

Operational sequence

Only valid transitions reach the control loop.

Discovery begins in Init. Mailboxes and process data are configured in PreOp. Distributed clocks and outputs are prepared in SafeOp. Cyclic exchange begins only after the session reaches Op. Each transition returns the next typed session handle.

Init

Discover the network.

Find slaves, read identity, and establish the topology the application expects.

PreOp

Configure communication.

Set up mailboxes and derive or apply the PDO configuration.

SafeOp

Prepare deterministic exchange.

Program sync managers and FMMUs, configure distributed clocks, prime outputs, and freeze the cyclic plan.

Exchange process data.

Run the compiled cyclic domain while diagnostics and bounded mailbox work remain explicit.

API Usage

The application cannot call the operational cycle on an initialization handle. It must complete the protocol sequence and receives a distinct handle at each state boundary.

let pre_operational = initialization
    .request_preop()?
    .configure_mailboxes()?
    .verify_identity()?
    .configure_pdo_from_sii()?;

let safe_operational = pre_operational
    .request_safeop()?
    .program_sync_managers()?
    .program_fmmus()?
    .configure_dc_from_eni_or_default()?
    .prime_outputs()?
    .freeze_cyclic(None)?;

let mut operational = safe_operational.request_op()?;
let exchange = operational.cycle_once()?;

Dedicated data path

The hardware transport boundary targets a dedicated NIC through DPDK. Cyclic receive buffers are caller-owned and the protocol core stays independent of packet transport.

Simulation before hardware

The same SDK runs against a simulator transport for topology, state-transition, PDO, mailbox, and recovery tests before a drive chain is available.

Visible diagnostics

Working counters, slave state, distributed-clock status, emergency messages, and bounded mailbox work remain observable to the application.

Availability

Evaluate on the intended drive chain.

The SDK, simulator, daemon tooling, and dedicated-NIC path are available for evaluation on your intended drive chain. Production deployment requires validation on the intended hardware, including cycle timing, drive behavior, fault recovery, and device compatibility.

Contact engineering@tinverse.com.