What Is an EtherCAT Master? A Practical Guide to EtherCAT Master Software

Every EtherCAT network has exactly one device in charge. Servo drives, I/O modules, and sensors all wait for it. That device is the EtherCAT master, and choosing it is one of the biggest decisions in a motion control architecture.

This guide explains what an EtherCAT master actually does, how a software master differs from a dedicated hardware controller, and what to check before you commit to one.

What an EtherCAT Master Does

EtherCAT uses a single-master, many-slave model. The EtherCAT Technology Group now calls these the MainDevice and SubDevices, but “master” and “slave” are still the terms most datasheets and tools use, so we use them here too.

The master is the one node that starts every exchange. It has four core jobs.

1. Send the frame every cycle

The master transmits a standard Ethernet frame onto the network. The frame passes through each slave in turn. Each slave reads the data addressed to it and inserts its own data as the frame goes by, then passes it on. The frame comes back to the master carrying fresh feedback from every device.

That “processing on the fly” design is what sets EtherCAT apart; we compare it with PROFINET IRT in EtherCAT vs PROFINET IRT.

2. Exchange process data

The cyclic payload is called process data, carried in PDOs (process data objects):

• RxPDO (master to slave): commands such as the control word and target position.
• TxPDO (slave to master): feedback such as the status word and actual position.

Separately, the master reads and writes configuration parameters over a mailbox channel. For servo drives this is usually CoE (CANopen over EtherCAT), using the object dictionary defined by the CiA 402 drive profile.

3. Hold the cycle time

The cycle time is how often the master sends that frame. A 1000 µs cycle is a 1 kHz update rate. A 250 µs cycle is 4000 Hz. Shorter cycles mean fresher commands and smoother, faster motion, but they also leave less room for timing error.

The master has to hit that interval every time. If a frame arrives late, the drive notices: watchdog alarms trip and the axis can stop.

4. Keep everyone’s clock in step

Every device has its own oscillator, and no two run at exactly the same rate. Distributed clocks (DC) fix this. The master measures the propagation delay to each slave and continuously corrects for drift, so every drive acts on its new command at the same moment (the SYNC0 event).

Our whitepaper Distributed Clocks in EtherCAT covers the mechanism in depth.

Managing the network

Around the cyclic loop, the master also runs the network:

• Scans the bus and identifies each slave by vendor ID and product code.
• Configures each slave from its ESI file (the XML description supplied by the device vendor).
• Moves slaves through the EtherCAT state machine: Init, Pre-Operational, Safe-Operational, Operational.
• Reports errors, dropped frames, and timing statistics.

Software vs. Hardware EtherCAT Masters

There are two broad ways to put a master on the network.

	Hardware master	Software master
Form	A dedicated PLC or motion controller with an EtherCAT port	A library or runtime on a standard PC
Real-time timing	Handled by the vendor’s controller	Depends on the OS, the network adapter, and the stack
Programming	Vendor’s tools and languages	Your own code, in general-purpose languages
Hardware choice	Locked to the vendor’s controller	Off-the-shelf PCs and Ethernet adapters
Integration	Separate box beside your application	Runs in the same computer as your application

A hardware master suits plants already standardized on one PLC vendor. A software master makes more sense when the machine already has a PC doing kinematics, vision, or a user interface, where a separate controller box only adds cost and another interface.

The catch is timing. A general-purpose PC was not built for real-time Ethernet, so a software master stands or falls on how well it handles the operating system and the network driver.

How to Choose EtherCAT Master Software

Operating system support and determinism

Find out which operating systems the master runs on, and how well it performs on each. These are not the same question. Desktop Windows and macOS are not deterministic operating systems. A master can run on them, but it cannot get the same timing it gets on a real-time Linux setup.

Ask for the shortest reliable cycle time on each platform, not just the headline figure.

Real-time behaviour on your hardware

Jitter is the variation in when each cycle actually happens. It decides whether a minimum cycle time is usable in production. Questions to ask:

• What jitter and maximum latency does the master achieve, and on what hardware?
• Does it include an optimized Ethernet driver, and for which network chips?
• Does it report latency, runtime, and clock drift so you can verify timing yourself?

API and integration

The API decides how much glue code you will write. Look for direct access to process data, mailbox (CoE) reads and writes, state-machine control, and DC configuration. Check that it works with the language and toolchain your team already uses.

Device support and configuration

Check that the master imports standard ESI files, so you don’t map PDOs by hand, and supports your devices’ drive profile (CiA 402 for most servo drives). Finally, ask whether you can trial it against your own drive before buying.

Where the Adeeb EtherCAT Master Fits

The Adeeb EtherCAT Master is a software master for standard PCs. It is the same stack that drives our own delta robots. Here is how it lines up against the checklist above:

• Cycle time: configurable in multiples of 250 µs. The 250 µs minimum (4000 Hz) is supported on Linux PCs with Intel Ethernet adapters that use the igc driver. For those adapters, the master includes an optimized user-space real-time Ethernet driver.
• Jitter: sub-microsecond. The kernel and architecture work behind that figure is in Achieving Sub-Microsecond Jitter with EtherCAT Distributed Clocks.
• Platforms: releases for Linux, Windows, and macOS share one cross-platform example application. We’re upfront about the limits: Windows and macOS aren’t deterministic, so cycle times there need to be longer than on real-time Linux.
• Distributed clocks: DC sync with a configurable shift time between frame send and SYNC0. Master shift mode is supported; slave shift mode is not yet.
• API: a C API covering cyclic process data, CoE reads and writes, state transitions, and CiA 402 operation mode. The full reference is in the EtherCAT Master C API documentation.
• Configuration: ESI files are dropped into a folder, and the master reads them during network initialization.
• Diagnostics: each run reports latency, runtime, and DC clock drift statistics.

The Linux getting-started video shows the whole process on a mini PC and a Yaskawa servo: network scan, state transitions, and pushing the cycle time down to 250 µs.

FAQ

Is an EtherCAT master the same as a PLC?

No. A PLC can contain an EtherCAT master, but the master is only the part that runs the network. A software master puts that function on a standard PC, next to your own application code.

Can an EtherCAT master run on Windows?

Yes, including the Adeeb EtherCAT Master. Because Windows isn’t a real-time operating system, expect longer practical cycle times and keep other CPU load low. For the shortest cycle times, use real-time Linux.

Do I need special network hardware?

EtherCAT slaves connect over standard Ethernet cabling, and the master uses a regular Ethernet port. For the Adeeb master’s 250 µs minimum cycle time, use a Linux PC with a supported Intel igc-driver adapter. Longer cycle times work on more general hardware.

Try It on Your Own Drive

If you’re evaluating EtherCAT master software for a new machine, start with the EtherCAT Master product page and its free trial. To see it running multiple axes at 250 µs, book a demo. If you have questions about your drives, OS, or cycle-time targets, contact our engineering team.