Abstract

Keywords

Introduction
Industrial Ethernet is now widely accepted, and nearly every fieldbus provides a migration path to Ethernet. Even though ODVA evolved from general devices communication via DeviceNet, the specification approach of CIP [1][2] already included a holistic view which included various kinds of communication crossing network boundaries. The sercos organization was founded to bring the interface between electric drives and machine tools controls from analogue +-10V to a digital standard. This lead to a highly standardized interface [3] reaching up to the application layer (called drive profile) and supported by many drives and controls vendors. The design was very much focused on the requirements of closed loop control and covers features that other systems didn't target, like synchronization better than 1μs and a scheduled TDMA system with fixed bandwidth allocation. The system was designed so that the hard real time features was never endangered under any circumstances. The task of migrating the system to Ethernet included finding a way to keep the RT features while allowing the use of the standard Ethernet features. Consequently, the scheduled TDMA approach was kept and the network separated from the standard Ethernet to keep the appropriate mechanisms and features, but a time slot for standard Ethernet communication was included to serve for commissioning and diagnostics purposes. In the meantime two customer requests were pushing for the following developments in the Industry: safety of machinery and . the reduction of the variety of the physical and structural cabling in machinery. - The need for increased functionality and reduced costs in safety of machinery lead to an integrated device solution communicating over the standard process interface. Many solutions were proposed, but a big portion of the implementation costs for safety resides in certification and its supporting process. In order to achieve synergy and to strengthen CIP Safety, sercos international and ODVA agreed to support CIP Safety on sercos and work together on the development and certification tasks. Migration to Ethernet unites fieldbusses to one physical layer, but does not on its own enable devices sharing a common network infrastructure. This paper describes scenarios to combine sercos III and EtherNet/IP compliant devices on an integrated network infrastructure. This will allow machine builders and users to reduce the cost and complexity of machine integration while retaining the ability to deploy their preferred suppliers' products and devices.
The sercos communication structure
While EtherNet/IP is mainly based on COTS Ethernet Infrastructure because of the wide spectrum of application it covers in the Industry, sercos has always used specialized hardware and scheduled communication to guarantee precision (e.g., in machine tools). The sercos topology started by using a single fiber optic ring structure. Migration to Ethernet enabled the ring to change for a physical line or be transferred to a double ring constructed by a single Ethernet cable ring. This enables support  for media redundancy, hot plug features and switching off parts of a machine.
The sercos cycle
The sercos system was designed for master slave communication operated by a single master. Figure 1 shows the sercos communication cycle which can be set in the range from 31.25μs up to 64 ms. There are up to 8 sercos telegrams, 4 master data telegrams (MDT) and 4 device telegrams (AT). This allows for up to 511 devices being controlled. All telegrams are sent by the master, but devices read the control data from the MDT and write their sensor or feedback dat into the AT. The synchronization is done by a special bit pattern in MDT0, the master sync field (MST). As a result synchronization is a matter of exact timing in the master, minimum jitter in each node an a compensation algorithm. This mechanism demonstrated excellent performance even with configurations of 100 nodes. Migration to Ethernet did not only aim at improving speed. A major advantage of this migration is the connection to the network and the use of standardized internet protocols. Due to very efficient usage of payload, the sercos telegrams use only part of the cycle time for the reserved sercos real time channel (RT).  For example, an application with 64 drive axis needs about 400μs of a 2ms cycle, which leaves 1.6 ms for other communication. The name of the time slot for non sercos Ethernet frames is defined as unified communication channel (UCC) which symbolizes the usage for all sorts of tasks, not only commissioning and diagnostics but also deterministic real time in the ms scale as needed for I/O and other common applications. To give OEMs the possibility to choose devices from their preferred suppliers, the UCC can be used to connect standard EtherNet/IP devices to a controller using sercos for coordinated motion applications. This means the controller needs a sercos master and an EtherNet/IP scanner implemented. Figure 2 shows both combined into a dual stack master. The motion controller runs the coordinated motion via sercos. When redundancy is not needed, devices are connected in line topology. The last sercos device detects a non sercos device at its ssecond Ethernet port and only forwards the non-sercos telegrams which are not targeted for itself via the second port. In the other direction the device forwards the arriving telegrams to the Dual Stack Master via its first Ethernet port using the UCC and buffering telegrams arriving during RT channel time. 2012 ODVA Industry Conference If the application needs a sercos ring for redundancy purposes, a special sercos switch called IP-Switch device needs to be incorporated into the ring to merge the EtherNet/IP packets into the sercos ring. EtherNet/IP devices can be added in arbitrary topology: star topology via switch (as shown in Figure 2), daisy chain via device integrated switches or even a DLR. Why was EtherNet/IP selected for this migration to Ethernet? EtherNet/IP is not only a proven technology on the market. EtherNet/IP also offers a wide choice of products, is well designed (collection of manageable objects), provides bridging to other networks, and can be implemented in a small footprint. By using CIP Safety the controller can also use a common safety stack available on EtherNet/IP and sercos.
Proof of Concept
As a dual master system is not yet available, a proof of concept has been made using a separate EtherNet/IP scanner module connected to the unused Ethernet port of the sercos master. A basic configuration with 3 sercos drives and 7 EtherNet/IP devices and an extended configuration with 64 sercos drives have been tested. The criteria were: no timeouts of EtherNet/IP connections . no broadcast conflicts - limits only by bandwidth or controller capacity . Additional requirements include use of common physical layer as cabling and connectors - predetermined number of devices at configuration stage The tests have been run and confirmed some known issues in the sercos specification. These have been fixed in the latest specification V1.3 [4]. (Verification is scheduled for August/September 2012.) The test not ot only checks for timeouts, but captures all Ethernet traffic in sercos and in the EtherNet/IP segment. The capture files were analyzed by a program detecting every single packet loss by evaluating the EtherNet/IP sequence counter. The reliability of the EtherNet/IP connections was definitely proven by the tests. As EtherNet/IP networks use QoS and as the CIP specification defines priorities for different types of packets there should be no conflict in priorities of EtherNet/IP packets. Here the design of the integrated switch assures the correct behavior: all packets going through the sercos node and included in the UCC have a higher priority than the packets being sent by the node itself, so no change of priority will be performed in the sercos part of the network.
Recommended devices
On the EtherNet/IP segment all devices can be used except devices using synchronization via IEEE158 (CIP Sync, CIP Motion), because sercos is based on synchronizing by using the MST. No support is provided for IEEE158. The introduction of products supporting CIP Safety to the market will push the request for the blended network design.