EtherCAT for Robotics: Component Stack, Timing, Isolation and Sourcing Guide
Published: June 13, 2026 | Category: Robotics
EtherCAT is widely used in robotics, motion control, machine automation, distributed I/O, and servo systems because it delivers deterministic communication with very low protocol overhead. For procurement teams, however, the challenge is not simply selecting “an EtherCAT chip.” A production-ready EtherCAT node requires a complete component stack: slave controller, Ethernet PHYs, magnetics or isolation components, host MCU, clocks, connectors, power rails, and PCB routing that preserves signal integrity.
That makes EtherCAT a supply-chain and BOM architecture problem as much as a networking problem. A robot controller can meet timing targets in the lab yet still become difficult to manufacture if the design depends on a single slave controller, a hard-to-source PHY, unusual magnetics, or a tightly constrained PCB stack-up. Likewise, a sourcing team can find an apparently equivalent Ethernet component that causes interoperability or timing problems because the original design assumptions were more specific than the BOM description.
This guide explains the EtherCAT component stack from a procurement perspective, with emphasis on slave controllers, PHYs, host interfaces, isolation, timing, PCB layout, qualification, second sourcing, and the information that should appear on an RFQ before a component substitution is approved.
EtherCAT Architecture: What the BOM Actually Contains
An EtherCAT slave node generally contains four functional blocks:
EtherCAT slave controller or ASIC
One or more 100BASE-TX Ethernet PHYs
Host processor or application MCU
Isolation, magnetics, connectors, clocking, and power components
The slave controller processes EtherCAT frames in hardware while the host MCU reads and writes process data. This division of labor is one of the reasons EtherCAT can achieve very low cycle times without requiring the MCU to parse every Ethernet frame in software.
For procurement, that means the EtherCAT slave controller is often the most architecture-specific device in the design. The MCU and PHYs may have broader alternatives, but the slave controller can define the host interface, port count, register map, and firmware integration.
Slave Controller: Treat It as a Strategic Component
Beckhoff's ET1100 is a well-known EtherCAT slave controller used in industrial automation and robotics. It supports multiple Ethernet ports and local host interfaces and has been used in many designs requiring deterministic industrial Ethernet.
ET1200 is another Beckhoff EtherCAT slave controller family used for lower-port-count applications. The exact controller should be selected according to required ports, process-data size, host interface, synchronization features, and board architecture.
For sourcing teams, the key point is that these devices should not be treated like generic Ethernet controllers. The slave controller is tied directly to the EtherCAT implementation and can be difficult to substitute after the firmware and PCB are frozen.
Procurement Checks for the Slave Controller
Exact manufacturer part number
Port count
Host interface type
Package
Temperature grade
Process-data memory requirements
Distributed-clock support where required
Lifecycle status
Authorized supply coverage
If the design is dependent on one controller family, procurement should treat it as a lifecycle-risk item and monitor availability before mass production.
Do Not Assume There Are No Alternatives
A common oversimplification is to say that EtherCAT slave controllers have “no alternatives.” In reality, several implementation paths exist depending on the application, including dedicated EtherCAT slave controller ASICs, microcontrollers with integrated EtherCAT slave functionality, FPGA-based implementations, and vendor-specific industrial-communications devices.
However, these options are not drop-in replacements for ET1100 or ET1200. A migration may require changes to firmware, PCB layout, host interface, certification, and testing.
For procurement, the useful classification is:
Pin-compatible alternate
Functionally similar controller requiring PCB changes
Integrated MCU/ESC redesign
FPGA or programmable-logic redesign
Knowing the migration path before a shortage occurs is more valuable than assuming the primary device will remain available forever.
Ethernet PHY Selection: More Flexible, but Still Critical
EtherCAT uses standard 100BASE-TX physical-layer technology, so the PHY portion of the BOM is usually more flexible than the slave controller. Industrial PHY families from Texas Instruments, Microchip, Analog Devices, NXP, and other suppliers can be candidates depending on interface and timing requirements.
Typical procurement requirements include:
100BASE-TX support
MII or RMII interface compatibility
Industrial temperature range
Low deterministic latency
Auto-negotiation behavior as required
Clock architecture
Package compatibility
EMI and ESD performance
Examples such as TI DP83822-family PHYs and Microchip KSZ80xx-family devices are commonly evaluated in industrial Ethernet designs, but engineering should confirm the exact PHY against the EtherCAT controller and implementation guide.
Dual-Port Nodes Multiply the PHY Supply Risk
Many EtherCAT devices use two Ethernet ports to support line or daisy-chain topology. This means each node may consume two PHYs and two sets of magnetics or connector-integrated transformers.
For a large robotics production run, the volume impact can be significant. A machine with dozens of EtherCAT nodes can require far more PHYs and magnetics than the number of controllers suggests.
Procurement should therefore forecast PHY and magnetics demand at the system level, not just per PCB.
Host MCU: Often Not the Timing Bottleneck
One of EtherCAT's advantages is that the slave controller handles frame processing in hardware. The host MCU typically reads and writes process data through an interface such as SPI, parallel bus, or another local interface depending on controller architecture.
This means the MCU does not need to parse the full EtherCAT protocol at wire speed. For many applications, a modern Cortex-M4, Cortex-M7, Cortex-M33, or comparable industrial MCU has sufficient performance to execute motion-control, sensing, and application logic while servicing the EtherCAT process-data exchange.
Procurement should still verify:
Host-interface bandwidth
Interrupt latency
Process-data size
Control-loop complexity
Memory requirements
Real-time operating system overhead
The safest sourcing strategy is to keep the application layer portable enough that the host MCU can be replaced without forcing a complete EtherCAT redesign.
Sub-100µs Cycle Times: Where the Real Bottlenecks Are
EtherCAT systems can support very short cycle times because frames are processed as they pass through the slave controller. The actual achievable cycle time depends on the full system: number of nodes, frame size, cable delay, slave processing delay, host access, application code, synchronization strategy, and master implementation.
For a sub-100µs robotic control loop, procurement should not assume that the MCU is automatically the limiting factor. In many systems, the more sensitive items are:
PHY latency and timing behavior
Clock quality
Signal integrity
Host-interface access time
Process-data memory handling
Network topology
This is why apparently minor substitutions in PHYs, magnetics, or clocks can require system validation even if the nominal Ethernet standard remains unchanged.
Isolation: Ethernet Magnetics Are Part of the Safety and EMC Design
Standard copper Ethernet links commonly use isolation magnetics between the PHY and external cable. In EtherCAT, those magnetics may be discrete transformers or integrated into the RJ45 or industrial connector assembly.
Procurement should preserve:
Turns ratio
Insertion loss
Return loss
Common-mode rejection
Isolation rating
Package and pinout
Temperature rating
PHY compatibility
Products from Pulse Electronics, Würth Elektronik, Halo, Bel, and other suppliers are common in industrial Ethernet designs. The exact approved part should come from the PHY or EtherCAT reference design whenever possible.
Digital Isolation Between Controller and I/O
Some robot architectures also require galvanic isolation between the EtherCAT logic domain and the local motor-control, sensor, or I/O domain. This is separate from the Ethernet isolation magnetics.
Digital isolators such as TI ISO77xx-family devices or equivalent products from Analog Devices, Broadcom, NXP, and others may be used on SPI, GPIO, fault, or control paths.
Procurement should confirm:
Isolation working voltage
Propagation delay
Channel direction
Default output state
CMTI
Power consumption
Package creepage
If the isolated interface sits in a safety-related control path, the approved part may also be tied to the functional-safety analysis.
Clocking: Small Component, Large Timing Impact
EtherCAT slave controllers and PHYs depend on stable reference clocks. The exact frequency and clock topology depend on the selected devices, but a typical industrial Ethernet design may use a 25 MHz crystal or oscillator for the PHY section.
Procurement should avoid substituting clocks solely by frequency. Engineering should verify:
Frequency tolerance
Load capacitance
ESR
Drive level
Startup behavior
Temperature stability
Jitter
Package
Clock substitutions can create difficult intermittent problems that appear as link instability rather than obvious component failure.
PCB Routing: MII/RMII and Ethernet Pairs Need Controlled Geometry
EtherCAT boards combine two types of sensitive routing: the digital interface between the slave controller and PHY, and the differential 100BASE-TX path between the PHY and magnetics.
Engineering should follow the controller and PHY layout guides rather than relying on universal fixed numbers for every design. Important practices typically include:
Controlled-impedance Ethernet differential pairs
Short PHY-to-magnetics routing
Minimal stubs
Careful return paths
Matched differential pair geometry
Proper termination
Clock isolation from noisy switching nodes
Separation from motor-phase and high-dV/dt traces
Rules such as “no vias” or “match every trace within exactly 1 mm” can be useful design targets in some layouts, but they should not be treated as universal procurement requirements unless the engineering drawing specifies them.
Connector Selection: RJ45 Is Not the Only Option
Robotics and industrial systems may use RJ45, M8, M12, or other industrial Ethernet connectors depending on environmental, mechanical, and ingress-protection requirements.
Procurement should compare:
Connector type
Shielding
Integrated magnetics or discrete magnetics
IP rating
Insertion cycles
Temperature range
Cable orientation
Mechanical keying
An alternate connector can change the EMI behavior or board footprint even if the Ethernet pinout appears similar.
EtherCAT BOM Sourcing Checklist
| BOM Area | What to Specify | Main Procurement Risk |
|---|---|---|
| Slave controller | Ports, host interface, package, lifecycle | Architecture lock-in |
| Ethernet PHY | MII/RMII, latency, temperature | Timing and interoperability |
| Magnetics | Isolation, insertion loss, pinout | EMI and link-quality changes |
| MCU | Host bandwidth, memory, real-time performance | Firmware migration effort |
| Clock | Frequency, tolerance, ESR, jitter | Intermittent timing faults |
| Digital isolator | Delay, working voltage, CMTI | Safety or timing impact |
| Connector | Mechanical type, shielding, IP rating | Mechanical and EMC requalification |
Single-Source Risk: Build a Migration Plan Before Allocation
EtherCAT slave-controller availability can become a strategic risk because the part is tied so closely to the implementation. Procurement should not wait until lead time expands before asking whether an alternate path exists.
During NPI, teams can document:
Primary EtherCAT controller
Potential alternate controller family
Host-interface differences
PCB changes required
Firmware migration effort
Certification or interoperability test impact
This does not eliminate the primary supplier dependency, but it gives the program a realistic response plan.
PHY and Magnetics Should Be Dual-Sourced Where Practical
The PHY and magnetics portion of the BOM is often easier to second-source than the slave controller. Procurement should work with engineering to qualify more than one supplier if the design volume justifies it.
Second sourcing should still include link testing, EMC validation, and temperature testing. A component that meets the Ethernet standard may behave differently enough to affect a tightly timed industrial network.
What to Include in an EtherCAT RFQ
A strong EtherCAT sourcing request should include more than the base part number.
Exact EtherCAT slave controller MPN
Required port count
Host interface
PHY part number or approved equivalents
Temperature grade
Connector type
Magnetics requirements
Isolation requirement
Clock requirement
Quantity and annual forecast
Target delivery schedule
Whether alternates may be proposed
Required traceability
For a robotics platform already in production, submitting the complete EtherCAT communication BOM can be more effective than sourcing only the slave controller. A shortage in the PHY, transformer, oscillator, connector, or isolator can stop the same board.
Common Procurement Mistakes
Mistake 1: Treating every industrial Ethernet PHY as equivalent. Timing, interface, clocking, and EMI performance still require validation.
Mistake 2: Assuming the EtherCAT MCU must be exceptionally fast. The slave controller handles most frame processing in hardware.
Mistake 3: Buying magnetics based only on 100BASE-TX labeling. Isolation, pinout, and PHY compatibility matter.
Mistake 4: Treating ET1100/ET1200 as ordinary controllers. They can create deep architectural lock-in.
Mistake 5: Using rigid PCB rules without the vendor layout guide. The approved geometry depends on the exact PHY, stack-up, connector, and board architecture.
Mistake 6: Ignoring lifecycle planning. Industrial networks often remain in production for many years.
How Aurora Components Supports EtherCAT and Robotics BOM Sourcing
Aurora Components Co., Limited supports OEMs, EMS providers, robotics companies, automation teams, and procurement departments sourcing components for EtherCAT, servo drives, motion-control systems, industrial Ethernet, machine vision, and distributed I/O.
EtherCAT BOMs can include slave controllers, Ethernet PHYs, MCUs, oscillators, magnetics, digital isolators, connectors, power-management ICs, and protection components from multiple manufacturers. A shortage in any one critical line can delay an entire robot controller or servo platform.
Aurora Components can assist with BOM sourcing, hard-to-find components, shortage requirements, obsolete and EOL parts, alternate sourcing, and multi-manufacturer cross-reference searches. For independently sourced industrial networking components, buyers should define traceability, packaging, inspection, date-code, and qualification requirements before purchase.
If your robotics or automation project is building an EtherCAT slave node, send the exact part numbers or complete communication BOM for sourcing review.
Website: www.auroraic.com
Email: info@auroraic.com
