EtherCAT servo systems: commissioning and troubleshooting
EtherCAT is a real-time Ethernet fieldbus that processes the frame on the fly at every node, and it is the standard choice for machines with many tightly synchronised axes. The answers below collect what is asked most in the field, from the ESI file and Distributed Clocks to a slave stuck in PRE-OP and working-counter errors.
6 questions answered
Basics
Commissioning
Troubleshooting
Basics
01
When should I choose EtherCAT over CANopen or Modbus?
Choose EtherCAT when the axis count grows, when the axes must move in tight synchronisation (interpolation, electronic cams, flying cut) and when the cycle time has to go below a millisecond. For a few independent axes with parameter access CANopen is usually enough, and Modbus RTU for monitoring and simple commands.
Synchronisation needed: EtherCAT with Distributed Clocks
How do I add an EtherCAT drive to the master project, and what is the ESI file for?
The ESI (EtherCAT Slave Information) file is the XML that tells the master the drive's PDO mapping, the modes it supports and its synchronisation settings. Install the ESI file into the master software's device repository first, then scan the network; a device that matches the installed description is added to the project with the right settings.
Download the ESI file from the Document Centre with the drive's full order code
The revision in the drive and the ESI revision must match, or the master warns
After the scan, check the PDO mapping for each axis
What are Distributed Clocks (DC), and when should I enable them?
Distributed Clocks lock every slave's local clock to one reference, so all drives apply the command at the same instant (the SYNC0 event). In cyclic synchronous position mode (CSP) and in coordinated multi-axis motion DC must be on; otherwise the axes drift against each other by small amounts that change from cycle to cycle.
The SYNC0 period must equal the master task cycle
The reference clock is usually the first DC-capable slave
DC off with CSP: a common cause of jitter and following error
For most servo applications 1 ms is a good starting point. For tight interpolation and high dynamics 500 µs or 250 µs can be used, but a shorter cycle raises the load on the master CPU. The right value is the shortest period in which the master completes its task every cycle without overrun; check the drive manual for the shortest period it supports.
Watch the task overrun counter; it must stay at zero
The frame grows with the axis count; choose the cycle accordingly
An EtherCAT slave stays in PRE-OP or SAFE-OP and will not go to OP. Why?
When a slave refuses a state transition it reports the reason in its AL Status Code, and that is the first thing to read. The most common causes are an ESI description in the master that does not match the drive firmware, an invalid PDO mapping, DC/SYNC0 settings that differ from what the slave expects, and the sync manager watchdog firing because no process data arrives in SAFE-OP.
Read the AL Status Code from the master's diagnostics
Compare the ESI revision with the one in the drive
Reset the PDO mapping to default and try again
With DC enabled, confirm the SYNC0 period equals the task cycle
I see working-counter errors and lost frames. Where do I start?
The working counter shows how many slaves processed the frame correctly; if it is lower than expected, one or more slaves could not process that cycle's data. It is almost always the physical layer: a damaged cable or connector, IN and OUT ports swapped, an unshielded cable, or an EtherCAT line running right next to power cables.
Use the master's per-port error counters to find the faulty segment
At most 100 m between two devices; shielded Cat5e or better
Wire in order: into IN, out of OUT
Route EtherCAT in a separate duct from motor power cables
