# EtherCAT Fundamentals: Frames, Topology, and Distributed Clocks > EtherCAT sends frames that each device reads and writes as they pass, so cycle time, topology, and clock synchronization become engineering decisions you can… - Canonical URL: https://wiki.aspotomasyon.com/article/ethercat-fundamentals-distributed-clocks - Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki) - Category: Modern Connectivity - Published: 2026-10-11 · Updated: 2026-10-11 - Reading time: 9 min · Language: English EtherCAT sends frames that each device reads and writes as they pass, so cycle time, topology, and clock synchronization become engineering decisions you can verify. ![EtherCAT Fundamentals: Frames, Topology, and Distributed Clocks — Read the frame → Check the topology → Sync the clocks → Verify the counter.](https://wiki.aspotomasyon.com/assets/diagrams/ethercat-fundamentals-distributed-clocks.svg) *EtherCAT Fundamentals: Frames, Topology, and Distributed Clocks — Read the frame → Check the topology → Sync the clocks → Verify the counter.* EtherCAT is an Ethernet-based fieldbus for I/O, drives, and motion control, where short cycle times and tight synchronization matter. Its defining trait is that the network does not relay messages device by device. A frame travels through the segment (several frames for a large process image), and each device takes its data from the frame or inserts its data as the frame passes. Most of EtherCAT's performance, and most of its commissioning pitfalls, follow from that design. This article covers frame processing, topology and cable redundancy, the working counter, distributed clocks, device description files, mailbox protocols, and where EtherCAT fits against PROFINET and EtherNet/IP. It uses MainDevice and SubDevice, the terms in the EtherCAT Technology Group's current technology description; older documents say master and slave. The full specifications are member documents, so confirm details against the version your devices implement. ## How a frame is processed on the fly The MainDevice, usually a PLC, motion controller, or PC with a standard Ethernet port, sends one or more frames per cycle carrying output data and a command for each SubDevice. Each SubDevice controller reads the commands addressed to it and inserts its input data in hardware as the frame moves downstream. At the end of a line, the last node returns the frame over the full duplex link. The ETG notes that the frame is delayed only by hardware propagation times. - **Addressing:** a logical address space of 4 GB lets several SubDevices share one datagram, and the MainDevice can refresh drives and I/O on different cycles. - **Design targets:** the ETG cites cycle times of 100 µs or less and jitter of 1 µs or less. Treat these as design targets; your measured values under production load are the acceptance evidence. ## Topology and cable redundancy Line, tree, and star layouts are supported, and drop lines can use ports built into many I/O modules, often without extra switches. The ETG states that a segment can hold up to 65,535 devices. Copper runs use 100BASE-TX up to 100 m between nodes, with fiber for longer distances. EtherCAT P adds power on the same cable. Cable redundancy closes the line into a ring by connecting the last node to a second MainDevice port. A software add-on in the MainDevice detects a break or node fault. Link detection in the SubDevices resolves the case in under 15 µs, so at most one cycle is disrupted, and the nodes need no special redundancy logic. ## Working counter and diagnostic evidence Each datagram carries a working counter. Every addressed SubDevice that can access its memory increments it. The MainDevice compares the result with the expected value from the configuration. On a mismatch, the datagram's data is withheld from the application, and node and link status show where to look. A mismatch means that data is not trustworthy for that cycle. Frames also carry a checksum that each SubDevice checks. A bad frame increments an error counter at the node where it occurred, and downstream nodes are informed. Comparing these counters localizes the fault, which a conventional party-line fieldbus cannot do. A boot-up scan compares the actual topology with the planned one. ## Distributed clocks for synchronization Distributed clocks give each SubDevice a local clock synchronized to a reference clock. Propagation delay along the cable is measured at start-up, and optionally during operation, and compensated in each device. The ETG states that the clocks agree to much less than 1 µs. Devices can then set outputs at the same instant and stamp inputs precisely. Motion benefits most. Position is sampled on the local clock rather than when the frame arrives, so microseconds of frame jitter do not distort the sampling interval. The MainDevice only has to send the frame early enough. Servo axes that must move together are the typical case; see [motion control with servo drives](https://wiki.aspotomasyon.com/article/motion-control-servo-systems). **Illustrative example** Assumed scenario, not a measured result: a packaging line with eight axes and 24 I/O stations on one segment. The commissioning record stores the reference device, the start-up delay measurements, and the synchronization status after a 30-minute run. The figures that matter come from the machine's own test, not from this example. ## Device description files and mailbox protocols Each SubDevice is described by an EtherCAT SubDevice Information (ESI) XML file. It lists process data, mapping options, mailbox protocols, and synchronization modes. The configuration tool reads the ESI files and exports an EtherCAT Network Information (ENI) file that the MainDevice uses at boot. Each device also stores basic data in an EEPROM, but full configuration needs the ESI. Acyclic traffic uses a mailbox channel. CAN application protocol over EtherCAT (CoE) reuses the CANopen object dictionary, PDO mapping, and SDO services, so CANopen firmware can often be reused, and the CiA 402 drive profile maps across. ADS over EtherCAT (AoE) adds routable services. TCP/IP can be tunneled through the mailbox without disturbing real-time data. ## Where EtherCAT fits against PROFINET and EtherNet/IP All three technologies serve cyclic I/O and drive control. EtherCAT is standardized through the IEC 61158 and IEC 61784 series, as the ETG notes. Choose between them by controller family, device ecosystem, timing, and the safety and security features required. The table summarizes what each technology owner publishes; confirm details for your product versions. | Aspect | EtherCAT | PROFINET | EtherNet/IP | | --- | --- | --- | --- | | Real-time mechanism | Frame processed on the fly by SubDevice hardware | Real-time communication with an IRT option for isochronous operation | CIP messaging over standard Ethernet and TCP/IP | | Topology | Line, tree, star; ring through cable redundancy | Switched Ethernet design per vendor guidance | Standard Ethernet switching per vendor guidance | | Device description | ESI XML files; ENI generated by the configuration tool | GSD / GSDML device description | EDS files | | Safety | Safety over EtherCAT | PROFIsafe over the same network | CIP Safety | | Security | EtherCAT Security Profile (ETG.1800) | Integrated cybersecurity features | CIP Security | | Time synchronization | Distributed clocks | IRT and TSN work listed by PI | CIP Sync | ## Commissioning and diagnostics procedure 1. **Check the library.** Match each device's ESI revision to its firmware and release notes before generating the ENI. 2. **Match the topology.** Wire the line, drop lines, and ring closure as drawn, run the boot-up scan, and clear every mismatch before enabling outputs. 3. **Check the process data.** Compare each mapped input and output with the I/O list, including data type and byte order. 4. **Confirm the counter.** Run cyclic traffic with outputs disabled and confirm no working-counter faults over a timed run. 5. **Check synchronization.** Confirm the intended reference device and that delay compensation completed. 6. **Test redundancy under lockout.** Under site procedure, with the machine in a safe state, open the ring at one point and record the diagnostic event and recovery. ## Pitfalls and when not to use EtherCAT - **MainDevice performance.** A software MainDevice can miss cycles when HMI, logging, or IT tasks compete for the CPU. Measure cycle time and jitter with those tasks running. - **Topology changes.** Hot Connect and drop lines change the frame path. Any added, removed, or reordered node needs a new ENI and a new scan. See [industrial network troubleshooting](https://wiki.aspotomasyon.com/article/industrial-network-troubleshooting-methodology) for symptom-based checks. - **Mixed traffic.** Ordinary IT traffic is not part of the EtherCAT design. Keep control segments free of it unless the MainDevice and device vendors document a validated arrangement. - **Safety.** Cable redundancy keeps communication running but is not a safety function. Safety over EtherCAT and any safety design belong with qualified functional-safety engineers and the applicable standard. - **Wrong layer.** EtherCAT suits short-cycle control. Plant-wide data access with browsing and security is better served by [OPC UA](https://wiki.aspotomasyon.com/article/opc-ua-protocol-overview) . ## Apply this to your project - Record the ESI revision, firmware version, and ENI version for every SubDevice. - Confirm that the scanned topology matches the drawing before any output or motion is enabled. - Record zero working-counter faults over a timed run under production load. - Record the synchronization status, reference device, and delay compensation results. - Test one controlled ring break and record the diagnostic event and recovery time. - Measure cycle time and jitter with the HMI and logging tasks running. - Document that non-control traffic is excluded from the segment, or record the validated exception. [Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance. ## Frequently asked questions ### Does EtherCAT need Ethernet switches? Usually not inside a machine segment. The ETG describes pure line topologies without the cascading limits of switches and hubs, and drop lines can use ports built into I/O modules. Switches or gateways may still sit at the boundary with plant networks. Confirm the design with the MainDevice and device vendors. ### What does the EtherCAT working counter tell me? It tells you whether a datagram was processed by the nodes the configuration expects. Each addressed node that can access its memory increments the counter, and the MainDevice compares the result with the expected value. A mismatch means the data should not be trusted for that cycle. It is a consistency check, not proof that the process is safe. ### Do I need the ESI file for every EtherCAT device? Yes, for full configuration. The ESI XML file describes process data, mapping options, mailbox protocols, and synchronization modes, and the configuration tool uses it to generate the ENI. Each device also stores basic information in its EEPROM, so the MainDevice can read basic features without the ESI, but that does not replace a correct process data configuration. ### How do distributed clocks differ from NTP or PTP? Distributed clocks synchronize the SubDevices on one EtherCAT segment through frame timing and delay compensation. NTP and PTP synchronize clocks across IT and plant networks for time stamping and logging. They can coexist but solve different problems. For plant-wide planning, see [industrial time synchronization](https://wiki.aspotomasyon.com/article/industrial-time-synchronization-plan). ### Can normal Ethernet traffic share an EtherCAT segment? The ETG describes tunnelling TCP/IP through the mailbox without affecting real-time data, which is the designed route. Ordinary IT traffic is not part of the EtherCAT design, so keep control segments free of it unless the MainDevice and device vendors document a validated arrangement. ## Continue the engineering work - [PROFINET and EtherNet/IP: Industrial Ethernet Protocols](https://wiki.aspotomasyon.com/article/profinet-ethernetip-industrial-ethernet-protocols) - [Motion Control with Servo Drives: Selection and Tuning](https://wiki.aspotomasyon.com/article/motion-control-servo-systems) - [Time-Sensitive Networking (TSN) for Industrial Ethernet](https://wiki.aspotomasyon.com/article/time-sensitive-networking-industrial) - [Industrial Ethernet Cabling and Infrastructure Design](https://wiki.aspotomasyon.com/article/industrial-ethernet-cabling) - [Industrial Network Troubleshooting Methodology](https://wiki.aspotomasyon.com/article/industrial-network-troubleshooting-methodology) Browse the [related technical library](https://wiki.aspotomasyon.com/category/modern-connectivity) or follow an [ASP project guide](https://wiki.aspotomasyon.com/guides) to plan the implementation sequence. ![A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded.](https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-context.svg) *A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded.* ## Primary references and further reading Use the original specifications and product documentation for implementation details. Examples in this guide are illustrative engineering scenarios, not published project results. - [EtherCAT Technology Group — EtherCAT technology](https://www.ethercat.org/en/technology.html) - [EtherCAT Technology Group — Downloads and specification index](https://www.ethercat.org/en/downloads.html) - [IEC — IEC 61158-1:2023 Fieldbus overview and guidance](https://webstore.iec.ch/en/publication/66931) - [PROFIBUS & PROFINET International — PROFINET technology](https://www.profibus.com/profinet-technology) - [ODVA — EtherNet/IP technology](https://www.odva.org/technology-standards/key-technologies/ethernet-ip/) --- Cite the canonical article: https://wiki.aspotomasyon.com/article/ethercat-fundamentals-distributed-clocks (EtherCAT Fundamentals: Frames, Topology, and Distributed Clocks, ASP OTOMASYON, updated 2026-10-11).