System Integration & Control Systems Design


Synchronising industrial Ethernet networks

June 2016 System Integration & Control Systems Design

Many machine building and manufacturing engineers have gotten used to industrial Ethernet as a way of life. While they are by no means extinct, traditional fieldbuses with custom hardware and cabling are in the rearview mirror for many enterprises.

The question today is no longer whether to use industrial Ethernet; the real question is how to take full advantage of it and how to ensure best practices are in place.

The general benefits of using one of the many industrial Ethernet protocols for machine networking are numerous, such as for I/O, the motion bus, and safety in many cases. However, some protocols have the potential not just to increase the speed of cycle times, but also to generate significant improvements in manufacturing precision, accuracy of processes, and system diagnostics.

The importance of synchronisation

Synchronisation, for example, is an area where the more advanced industrial Ethernet protocols can make an immediate mark. By implementing synchronisation, a consistent time base can be created across applications for any number of spatially separated industrial Ethernet-connected devices and machine sections, e.g., for applications with multiple motion axes to achieve a path through space of a robotic arm, or those involving measurement technology for diagnostics of bearing wear. Synchronisation is a key element in modern automation systems to ensure that both simple and complex devices are always synchronised to each other, to external applications, and to events in a reliable, repeatable manner. Device-level digital communication systems (fieldbuses) give the developers and end users of devices the opportunity to network these devices together, with industrial Ethernet being the most recent and most widely accepted entry into this market. What technologies are available today for synchronising a network of Ethernet-connected devices, and how can this synchronisation be used to the advantage of the automation engineer?

This article examines two different approaches to industrial Ethernet network synchronisation. The first is IEEE 1588, which is used in many different fieldbus protocols, Internet applications, and switched network topologies. The second approach relates to the concept of distributed clocks as used by EtherCAT, an open real-time Ethernet network. These different approaches, with pros and cons, will be covered briefly.

IEEE 1588-PTP

IEEE 1588 precision time protocol (PTP) offers a solution for implementing network-wide synchronisation down to sub-microsecond levels across a variety of transmission media, including over Ethernet. This standard has been adopted by several of the industrial Ethernet fieldbus protocol providers as the means of achieving temporal synchronisation in their respective technologies.

The standard does not specify some key parameters for devices, such as the type and frequency of device oscillators. Therefore, there can be various qualities of clocks in a given system, some better than others. A slower clock will have less time resolution and, therefore, will be less accurate with its time-stamping. Because of this, the IEEE 1588 network has to determine the best master clock (BMC) to use in the network, a negotiation algorithm that involves communicating device parameters to each other and determining the best device to use as the reference clock. Obviously, if all the devices have lower-quality clocks, then the overall BMC may still not offer the performance the user desires. If the network becomes larger, spanning through several subnets may be required, and special switches with IEEE clocks built in will be required, each becoming the BMC of each subnet.

After determining the BMC, the time delay between it and the other IEEE 1588 devices must be determined and periodic timing corrections to the BMC must be issued. Because in IEEE 1588 this has to occur in a switched network environment, the routing delays depend highly on the topology, and each additional switch not only adds delay, but additional devices on the network also increase network traffic. This means that traffic becomes more jittery and susceptible to being queued in a network switch, causing a considerable amount of jitter overall.

The actual time-stamps that are accessed and read can vary somewhat in an IEEE 1588 system. The so-called asynchronous time-stamp reads occur from one of two places: either a specialised Ethernet transceiver chip, or specialised media access control; both accessed from software on the host microcontroller via an interrupt. Synchronous time-stamp reads occur when they are inserted into the message as it enters the device. This requires additional specialised hardware, as the time-stamp addition changes the cyclic redundancy code of the Ethernet frame, which must then be recalculated. The advantage here is that the time-stamp and data match. Both of these approaches require a microcontroller (as well as software, RAM, etc.) to be designed into every slave device, which may be overkill for simple devices.

Distributed clocks push precision to the nanosecond level

As another way to implement synchronisation, EtherCAT is an example of an industrial Ethernet system that uses distributed clocks (DCs). These DCs are built into the associated EtherCAT slave controllers (ESCs), so there is no external circuitry, or special infrastructure required for implementing DCs. ESCs are the chips that implement the EtherCAT protocol in hardware. Devices with and without DC functionality can be mixed freely in the same network with no impact to the synchronisation quality of the network. The EtherCAT specification dictates the frequency and quality of the DC device’s oscillator. Therefore, there is no need for a BMC determination to be made. Any DC device can be the reference master clock. By operating principle, the reference clock is always the first EtherCAT slave that has DC functionality enabled. The advantage of this is that there is no negotiation required, and all slave devices have the same oscillator quality. Furthermore, the method of distributing the time from the reference clock is extremely efficient and elegant.

Because of the processing-on-the-fly operating principle of EtherCAT, every frame is routed in a cut-through fashion through every slave of an EtherCAT network (up to 65 535 slaves). Regardless of which slave is, or is not, being addressed, every frame goes through each slave device in the same path every time (there is no active routing of frames). This results in the same timing throughout the network. Each slave can predictably calculate how long it takes for data to pass between the forward direction (Tx) and returning direction (Rx), and the master also knows the exact EtherCAT network topology. This is important because the master can easily calculate the propagation delay between any two points in the network with these sets of data, such as between its reference clock (always the first DC-enabled device in the network) and each additional DC-enabled slave. This calculation needs to be done only once for a given network.

After calculating the propagation delay from the reference clock to an individual slave, this value is given to the slave, and each slave receives its unique propagation delay value. This is done so that each slave can set and maintain its local clock to that of the reference clock. For drift compensation, the master simply adds a very small instruction (16 bytes) to every cyclic frame, which grabs the time from the reference clock and distributes it to all other slaves. Each slave will compare the sum of the received time value from the reference clock, plus the propagation delay to its own local clock value and determine if it is running fast or slow. Compensation is done simply by adjusting how much time is counted for each pulse of its local oscillator, thereby closing a phase loop to the reference clock.

The performance of DCs is independent of the network topology, number of slave devices, and jitter of the frames coming from the master. Real-world jitter values of less than 100 nanoseconds are regularly achieved. The main factor in tightening the phase lock loop is simply the need to issue the time distribution command more often. Because neither the jitter of the network nor the timekeeping of the individual slave devices is impacted by any jitter of the Ethernet frames, the EtherCAT network doesn’t require any special master card to facilitate jitter-free frames. As long as the data are received by the farthest slave prior to the network-wide time interrupts to use it, there are no problems with frame jitter. All EtherCAT masters calculate how far in advance they need to begin sending out the frame based on any NIC jitter, any delay and jitter in the network, as well as the length of the frame itself.

Additionally, the DC unit that facilitates this synchronisation does not require the additional complexity or cost of a microcontroller. So, even low-cost digital I/O can be constructed of only the EtherCAT slave controller chip, an EEPROM, and the driver circuitry for the input/output signals. Yet this can deliver output signals that can be commanded down to the nanosecond, or latch in time values on rising or falling signal edges (configurable) with the same nanosecond resolution, all without the addition of a microcontroller.

Conclusion

Both IEEE 1588 and DCs offer the automation engineer the ability to implement a network of highly synchronised devices spread across a large area and long network distances. Whereas IEEE 1588 offers a viable solution for Internet and switch-based protocols, EtherCAT uses the more streamlined, bandwidth-efficient DC solution, which also ensures very low jitter.

Whereas IEEE 1588 requires special and complex microcontroller-based hardware even for the most simple of digital I/O devices, EtherCAT DC devices can be implemented without microcontroller support, resulting in lower device and system costs. These two synchronisation schemes can still be used together, bridged via boundary devices. This allows the network time to be shared between an EtherCAT network and an IEEE 1588-based system. Between these two synchronisation schemes, automation engineers can develop bottom-up or top-down architectures to meet the demands of their application or their customers.

For more information contact EtherCAT Technology Group, +49 911 540 56 226, press@ethercat.org, www.ethercat.org

Due to space constraints, an abridged version of the original article appears in print. Download the full article, including extra diagrams and a comparison of the practical application of the two technologies at http://instrumentation.co.za/+J957





Share this article:
Share via emailShare via LinkedInPrint this page

Further reading:

Four ways the global parts shortage has led to innovation and openness
System Integration & Control Systems Design
For those who use automation parts, the unpredictable nature of the supply chain is one of the biggest problems faced today. The shortfall has impacted every industry, but automation components have been especially affected.

Read more...
Iritron’s year of consolidation
Iritron Editor's Choice System Integration & Control Systems Design
Despite the multiple challenges faced by businesses in South Africa, the buoyancy of the technology sector worldwide has produced some green shoots for automation specialist, Iritron.

Read more...
Five edge opportunities for SIs to maximise revenue in 2024
Editor's Choice System Integration & Control Systems Design
System integrators continue to face the challenge of doing more with less – supporting complex operations, while meeting production schedules with limited resources, and innovating to increase efficiency, maximise safety and reduce risk.

Read more...
Condition monitoring in a forging press retrofit
Beckhoff Automation System Integration & Control Systems Design
Significantly increased vibration on machines can result in many forms of negative impacts such as reduced system performance or damage to the machine and foundation. Using the example of retrofitting a forging press with a maximum press force of 2000 tons, Wölfel Engineering explains how efficiently the process was tailored and implemented with PC-based control and measurement technology from Beckhoff.

Read more...
System integration in the digital age
System Integration & Control Systems Design
To meet the challenges of an increasingly competitive marketplace, many manufacturers (end users) must focus on their core competencies and outsource the rest to experts.

Read more...
Choosing a system integrator
Editor's Choice System Integration & Control Systems Design
Automation is an essential part of manufacturing today. Whatever the size, an upgrade or migration project can be complex, and the risks can be high. This is where system integrators (SIs) can help. They can bring together complex subsystems or components of a larger system and make them operate as a whole.

Read more...
Iritron awarded international contract for furnace control
Iritron System Integration & Control Systems Design
Iritron has been awarded two international, multimillion-Rand furnace drying projects. The company has extensive expertise in furnace drying control systems, and provides solutions in the fields of electrical, instrumentation, control systems, and decision support systems.

Read more...
Capitalise on risks by turning them into opportunities for growth
Iritron System Integration & Control Systems Design
In spite of the challenges facing the global and local economy, systems integration expert, Iritron remains optimistic for the year ahead, and believes that there are significant opportunities to be found during a challenging economic climate.

Read more...
Control loop case history 185: Temperature cascade control on boiler desuperheaters.
Michael Brown Control Engineering Editor's Choice System Integration & Control Systems Design
This is a wonderful example of how the use of a cascade flow control still allowed excellent control of the primary temperature control loop to be achieved, in spite of a valve with severe problems.

Read more...
Loop Signatures 15: Digital controllers – Part 7: The D term, concluded
System Integration & Control Systems Design
This third and final article on the subject of the derivative term in digital controllers deals with choosing the right response if you wish the derivative action to work on both setpoint changes and load changes.

Read more...