EtherCAT Motor Control with the SOLO SOM

Introduction

EtherCAT updates a full network of axes in cycles as short as 100 microseconds, with jitter under 1 microsecond between nodes. That is why it became the default fieldbus for synchronized, deterministic multi-axis motion. If you build machines that move many motors in lockstep, a slower bus shows up as ragged motion and wasted cycle time.

This article is about one concrete question: how to do EtherCAT motor control with the SOLO SOM. We cover the protocol layers that matter, CoE and CiA 402, distributed clocks, the cyclic synchronous modes, how to wire the network, and how to bring up a first axis. The goal is a working EtherCAT servo drive node on a SOLO board, not a survey of the standard.

What the SOLO SOM Adds

The SOLO SOM is a system-on-module that runs the same motor control core as the rest of the SOLO line, with the fieldbus brought out on the carrier. It adds an EtherCAT interface to SOLO, so you can drop a SOLO axis into an EtherCAT network the same way you would any other servo node.

In practice that means the SOM speaks CoE (CANopen over EtherCAT) and follows the CiA 402 drive profile, so your master sees a standard servo drive object dictionary. The motor control work that SOLO already does, field oriented control, encoder handling, current loops, stays on the module. The SOM layers the network on top. You keep the control core you know and gain a deterministic, real-time link to the rest of the machine.

Takeaway: the SOM turns a SOLO axis into a standard EtherCAT drive node, without changing the control core underneath.

EtherCAT in 60 Seconds

EtherCAT is an Ethernet-based fieldbus built for motion. A single master sends one frame that passes through every slave in turn. Each node reads its slice of the frame and writes its reply on the fly, as the frame moves through, so one pass updates the whole network. This “processing on the fly” is what gives EtherCAT its low latency and tight synchronization across many axes.

If you want the background before going further, two existing guides cover it: EtherCAT for motor controllers explains the bus itself, and EtherCAT servo drives covers how drives sit on it. For the wider family of deterministic buses, see time-sensitive protocols.

CoE: CANopen over EtherCAT

EtherCAT carries several application layers. For motion, the common one is CoE, CANopen over EtherCAT. CoE reuses the CANopen application model, the object dictionary and the PDO concept, and runs it over the EtherCAT transport. The practical benefit is that the drive profile and tooling you may already know from CANopen carry straight over.

CiA 402 on EtherCAT

The drive profile is CiA 402, the same profile used on CANopen. It defines the state machine, the modes of operation, and the standard objects a master uses to command a servo drive. On the SOLO SOM, the master walks the CiA 402 state machine to enable the drive, then commands position, velocity, or torque through the mapped objects.

We do not repeat the full profile here. The state machine, the modes of operation, and the object dictionary details live in our guide to the CiA 402 drive profile with SOLO. The point for EtherCAT is that the profile does not change. CoE carries the same CiA 402 objects over the EtherCAT transport.

Object Dictionary and PDO Mapping

Each axis exposes an object dictionary, a table of parameters and process values addressed by index and subindex. Two kinds of access matter. SDO access is for setup and one-off reads, like writing a current limit during configuration. PDO mapping is for the cyclic data exchanged every cycle, like target position out and actual position in.

PDO mapping is where you decide what travels on every frame. A typical cyclic position setup maps target position and control word in the RxPDO, and actual position, velocity, and status word in the TxPDO. Keep the cyclic data lean. Map only the objects the loop needs each cycle, and use SDO for the rest. A smaller PDO leaves more room on the bus and keeps the cycle short.

Determinism and Synchronization

Multi-axis motion only looks coordinated if every axis acts on the same instant. EtherCAT gets this from two mechanisms working together: a shared clock and synchronous operating modes.

Distributed Clocks

Distributed clocks, often written DC, give every node a common time base. The master aligns the local clocks of all slaves to a reference, usually the first DC-capable slave, and corrects for propagation delay down the line. Once aligned, each axis can act on a sync signal at the same moment, with offsets typically held under 1 microsecond.

Without DC, axes apply their setpoints whenever their frame arrives, and small offsets between nodes turn into visible path error on coordinated moves. With DC on, the master schedules the same trigger instant for all axes. That shared instant is what makes interpolated, multi-axis paths come out clean.

Cyclic Synchronous Modes (CSP/CSV/CST)

CiA 402 defines three cyclic modes that fit EtherCAT well. In each, the master sends a fresh setpoint every cycle and the drive closes its loop locally.

The advantage over CANopen is direct. EtherCAT plus distributed clocks plus a cyclic synchronous mode means every axis gets a new setpoint and a shared trigger on each cycle, generally at higher rates and tighter sync than a CANopen network reaches. For one axis the gap is small. For many axes that must stay in step, it is the reason to pick EtherCAT.

Takeaway: distributed clocks set a shared instant, and the cyclic synchronous modes make every axis act on it.

Wiring an EtherCAT Servo Network

EtherCAT uses standard Ethernet cabling and a simple physical layout. The basic shape is a line: the master connects to the first slave, that slave connects to the next, and so on down the chain. Node order on the cable defines the logical order the master sees, so plan the sequence before you crimp.

Most EtherCAT slaves, including drives, have two ports, IN and OUT. You daisy-chain from the OUT of one node to the IN of the next. Loop the last node’s OUT back to a spare master port and the line becomes a ring, which adds cable redundancy: if one link breaks, the network keeps running from the other side. A few rules keep bring-up smooth: wire IN to OUT consistently, do not leave the chain ambiguous, and keep the physical order matching the order you configured in the master.

Bringing Up the SOLO SOM

With the network wired, bringing up a SOLO SOM axis is two steps: tell the master what the node is, then command a first move.

Master Configuration and ESI File

Every EtherCAT slave ships an ESI file, an XML description of the device that the master imports. The ESI lists the object dictionary, the available PDOs, and the supported modes, so the master knows how to talk to the node. Load the SOLO SOM ESI into your master tool (TwinCAT, Acontis, IgH, or similar), scan the bus, and the SOM should appear as a CoE drive in the configured order.

From there you set the cycle time, enable distributed clocks, and choose your PDO mapping for the mode you plan to run. Start simple. One axis, CSP, a modest cycle time like 1 millisecond, DC enabled. Confirm the master reaches the OPERATIONAL state with no working-counter errors before you command motion.

First Motion Test

The first move follows the CiA 402 state machine. Walk the drive through the enable sequence with the control word, watch the status word confirm each transition, and bring the axis to Operation Enabled. Then feed a small, slow target through your chosen cyclic mode, a few degrees in CSP, and check that actual position tracks the target.

Keep the first test conservative: low speed, soft limits set, e-stop within reach. Once a single axis tracks cleanly under DC, you add the next node and repeat. Multi-axis sync is just this, done for every node on the same shared clock.

Takeaway: load the ESI, reach OPERATIONAL, walk the CiA 402 state machine, then command one slow move before scaling up.

EtherCAT vs CANopen: When to Choose Which

Both buses run CiA 402, so the drive profile is the same. The choice is about the network, not the profile.

Choose EtherCAT when you have several axes that must move in lockstep, or when cycle time and jitter decide the result, like interpolated paths or gantry load sharing. Choose CANopen when the network is smaller, node count is low, and CAN wiring already fits the machine. For a CANopen network of multiple SOLO units, the bus design and addressing live in a separate guide on running several SOLO nodes on one CANopen bus.

How SOLO Covers EtherCAT Integration

SOLO supports EtherCAT integration through the SOLO SOM and its CoE implementation of the CiA 402 profile, so a SOLO axis behaves like a standard drive node on your master. We provide the ESI file, the libraries, and the documentation you need to configure the module, map PDOs, and run the cyclic synchronous modes. The motor control core, field oriented control and closed-loop feedback, keeps improving on the same module, so the network layer sits on top of control you can rely on. You can find the libraries, SDKs, and integration docs on the SOLO resources page.

Conclusion

EtherCAT motor control with the SOLO SOM comes down to a few layers working together. CoE carries the CiA 402 drive profile, so your master sees a standard servo drive. Distributed clocks and the cyclic synchronous modes (CSP, CSV, CST) give every axis a shared instant and a fresh setpoint each cycle, which is what makes multi-axis motion stay in step. Wiring is plain Ethernet in a line or a ring, and bring-up is load the ESI, reach OPERATIONAL, then command one slow move. If you are ready to integrate a SOLO axis over EtherCAT, the SOLO resources page has the ESI file, libraries, and docs to get the first node running.

FAQ