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, [email protected], 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
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version