EtherCAT

What it is

EtherCAT is a real-time fieldbus that runs on standard Ethernet hardware. In motion control it is the communication layer you reach for when every axis of a machine has to be driven in the same cycle, on the same time base. SMB TECHNICS is a member of the EtherCAT Technology Group; the definitions below follow that organisation's own published technology documentation.

What separates EtherCAT from ordinary Ethernet is that it does not cut the data into one message per device. A single telegram passes through every device on the line. Each device reads the section addressed to it while the telegram is still moving, and writes its own data into the same frame on the way through. In the organisation's own words: each EtherCAT SubDevice reads the data addressed to it “on the fly”, and inserts its data in the frame as the frame is moving downstream.

That one sentence explains EtherCAT's whole character. Adding an axis is not adding a message; it is making an existing frame a few bytes longer. Communication load therefore does not explode as the axis count grows, and the cycle time stays predictable.

How it works

The main focus during EtherCAT's development, in the organisation's own words, was short cycle times (≤ 100 µs) and low jitter for accurate synchronization (≤ 1 µs). For motion control the second figure is the decisive one. How well axes track each other is not governed by average latency but by how much that latency varies from cycle to cycle. When jitter grows, contour error grows with it, and on a two-axis circle that surfaces as visible distortion in the part.

Synchronisation comes from distributed clocks. Device clocks are aligned in hardware and, again in the organisation's words, the clocks are simultaneous to within much less than 1 µs of each other. A motion command is therefore applied “at this timestamp”, not “now”: what matters is not when the command reached the device but when the device acts on it.

On efficiency, the telegram's maximum effective data rate increases to over 90 %. The reason is the same working principle: a whole Ethernet frame is not spent on one small block of process data, because many devices share the same frame. Up to 65,535 devices can be connected to one EtherCAT segment, so network expansion is, in the organisation's words, virtually unlimited.

On the controller side no dedicated communication processor is needed: the MainDevice uses a standard Ethernet Media Access Controller, and the implementation runs on any hardware platform with an available Ethernet port. That removes EtherCAT as a hardware cost line in a controller.

Where cable redundancy is used, break conditions are detected and resolved with a recovery time of less than 15 µs, so at most a single communication cycle is disrupted.

On the drive side EtherCAT does not invent a new device model. With the CoE protocol (CANopen over EtherCAT) it provides the same communication mechanisms as the CANopen standard EN 50325-4: object dictionary, PDO mapping (Process Data Objects) and SDO (Service Data Objects). Device profiles such as the CiA 402 drive profile can also be reused for EtherCAT. The practical consequence is that the drive state machine and the operating modes engineers know from CANopen are the same over EtherCAT — changing protocol does not mean rewriting the application logic.

When to choose it

The deciding criteria are axis count and synchronisation need. If several axes must move in step with one another — contouring, electronic cam and gear, flying shear, coordinated robot kinematics — the binding constraint is the cycle time and jitter budget, and that is precisely the problem EtherCAT was designed for.

It is equally the safe choice when the field layer is expected to grow: axes and I/O nodes added later do not force the architecture to be rethought. On a single-axis machine where cycle time is not critical and communication is only used for start, stop and status, EtherCAT's determinism goes unused; there, CANopen or Modbus RTU is usually sufficient and the wiring is simpler.

There is an engineering cost as well: topology and cabling order carry meaning, because the scan order determines device addressing. That is not a weakness but a consequence of how EtherCAT works — it just has to be accounted for while the machine is still on paper.

At SMB

In the SMB catalogue EtherCAT is not a feature confined to one series but a variant available across the drive families. The EtherCAT variants of the SD24-LP and SD-LP families, the SDU3 series and the EtherCAT models of the SDE series are all parts of the same architecture, and an EtherCAT interface is present on the motion controller and CNC panel PC side as well.

One point deserves emphasis: the SD-LP family offers the same drive in EtherCAT, CANopen and Modbus RTU variants. The choice of protocol is a variant choice, not a change of platform. Building the first version of a machine on Modbus RTU and moving to EtherCAT for the second does not require changing the drive family, the motors or the cabling.

The list below is not hard-coded: it is generated live from the products bound to the EtherCAT node of the catalogue, so when the catalogue changes this page changes with it.

Common questions

Does EtherCAT need a special network card? Not on the controller side. In the organisation's own words, the MainDevice uses a standard Ethernet Media Access Controller without an additional communication processor, and the implementation runs on any hardware platform with an available Ethernet port. The subordinate devices do carry a dedicated controller that processes the frame on the fly, but that arrives inside the drive; it is not a part to be sourced separately.

Can EtherCAT share a cable with ordinary Ethernet? The cabling infrastructure is standard Ethernet infrastructure, but an EtherCAT segment depends on the determinism of its own traffic. The sound practice is to keep the field segment separate from the office network and give it its own port on the controller.

How many devices can be connected? Up to 65,535 devices can be connected to one EtherCAT segment, so network expansion is virtually unlimited. The real limit is not that number but your cycle-time budget: because every device's data travels in the same frame, the frame grows, and at some point it no longer fits the cycle you are aiming for.

If I move from CANopen to EtherCAT, how much of my application changes? The drive-side model is largely preserved. With CoE, EtherCAT provides the same mechanisms as the CANopen standard EN 50325-4 — object dictionary, PDO mapping and SDO — and the CiA 402 drive profile can be reused. What changes is mostly topology, addressing and commissioning.

What happens if a single cable breaks? Where cable redundancy is used the condition is detected and resolved with a recovery time of less than 15 µs, so at most a single communication cycle is disrupted.