SERCOS III Communication

A freely available real-time communication standard for digital drive interfaces, SERCOS III not only specifies the hardware architecture of the physical connections but also a protocol structure and an extensive range of profile definitions. For SERCOS III, effectively the third generation of the Sercos Interface that was originally introduced to the market in 1985, Standard Ethernet according to IEEE 802.3 serves as the data transfer protocol. This communication system is predominantly used in Motion Control-based automation systems. A registered association, sercos International e.V., supports the technology‘s ongoing development and ensures compliance with the standard.

How It Works

While specific hardware is categorically needed for the slave, a software solution is also feasible for the master. The sercos user organization provides a SERCOS III IP core to support FPGA-based SERCOS III hardware development. SERCOS III uses a summation frame method. Network nodes must be deployed in a daisy chain or a closed ring. Data is processed while passing through a device, using different types of telegrams for different communication types. Due to the full-duplex capability of the Ethernet connection, a daisy chain actually constitutes a single ring, whereas a proper ring topology will in effect provide a double ring, allowing for redundant data transfer. Direct cross-traffic is enabled by the two communication ports on every node: in a daisy chain as well as a ring network, the real-time telegrams pass through every node on their way back and forth, i.e. they are processed twice per cycle. Hence, devices are capable of communicating with each other within one communication cycle, with no need to route their data through the master. Besides the real-time channel, which uses time slots with reserved bandwidths to ensure collision-free data transfer, SERCOS III also pro- vides for an optional non-real-time channel. Nodes are synchronized on the hardware level, prompted by the first real-time telegram at the beginning of a communication cycle. The master Synchronization Telegram (MST) is embedded into the first telegram for that purpose. Ensuring high precision by keeping synchronization offsets below 100 nanoseconds, a hardware-based procedure compensates for runtime delays and variations in it resulting from the Ethernet hardware. Various network segments may use different cycle clocks and still achieve fully synchronized operation.