Breaking the bottleneck of control performance, the synchronization of multi-axis motion control is achieved in this way

This article introduces a new concept for synchronizing motor drives from the network controller to the motor terminals and sensors. The proposed technique can significantly improve synchronization, thereby significantly improving control performance.

To illustrate the limitations of existing solutions, consider a two-axis networked motion control system, as shown in Figure 1. The motion control host sends commands and instruction values ​​over a real-time network to two servo controllers, each of which constitutes a slave node on the network. The servo controllers themselves consist of a network controller, motor controller, power inverter, and motor/encoder.

Figure 1. A typical two-axis networked motion control system.

Real-time network protocols use different methods to synchronize slave nodes with the master, and one common method is to configure a local synchronized clock at each node. This consensus on time ensures that the command values ​​and commands for all servo axes are tightly synchronized. In other words, all network controllers on the real-time network remain synchronized.

Typically, there are two interrupt lines between the network controller and the motor controller. The first tells the motor controller when it needs to collect input and put it on the network. The second tells the motor controller when to read data from the network. Following this approach, data is exchanged between the motion controller and the motor controller in a synchronous manner, and very high timing accuracy can be achieved. However, it is not enough to simply transmit synchronous data to the motor controller; the motor controller must also be able to respond to the data in a synchronous manner. Without this ability, the motor controller cannot fully utilize the timing accuracy of the network. The motor controller's I/O will have problems responding to command values ​​and commands.

Each I/O in a motor controller, such as pulse width modulation (PWM) timers and ADCs, has inherent latency and time quantization. For example, let’s look at the PWM timer that generates the gate drive signal for the power inverter shown in Figure 2. The timer generates the gate signal by comparing the command value Mx with an up-down counter. When the control algorithm changes Mx, the new duty cycle does not take effect until the next PWM cycle. This is equivalent to a zero-order hold effect, meaning that the duty cycle is only updated once or twice (if double update mode is used) within each PWM cycle T.

Figure 2. Duty cycle update of the PWM timer.

On a real-time network, no matter how tightly the data exchange is synchronized, the time quantization of the PWM timer will ultimately be the determining factor for axis synchronization. When a new command value is received, it is not possible to respond to it before the new duty cycle takes effect. This results in a time uncertainty of up to one PWM period (typically in the range of 50μs to 100μs). In effect, there will be an undefined and variable phase relationship between the network synchronization period and the PWM period. Comparing this to the time uncertainty of less than 1μs on a real-time network, it is clear that the motor controller's I/O plays a more critical role in network-synchronized motion control. In fact, it is not the real-time network that determines the synchronization accuracy, but the system I/O.

Referring again to Figure 1, the system has three synchronization domains, A, B, and C, which are not tied together. They are not actually synchronized, with a variable uncertainty of up to one PWM period.

The effects of timing uncertainty can be clearly seen in high-performance multi-axis servo systems for applications such as robotics and machine tools. Variations in timing offsets between motor-controlled axes at the I/O level can have a direct and significant impact on the final 3D positioning accuracy of the robot or machine tool.

Consider a simple motion profile, as shown in Figure 3. In this example, the motor speed command value (blue curve) increases and then decreases. If the ramp rate is within the capabilities of the electromechanical system, the actual speed expectation will follow the command value. However, if there is a delay anywhere in the system, the actual speed (red curve) will lag behind the command value, resulting in a position error Δθ.

Figure 3. Effect of timing delay on position accuracy.

In a multi-axis machine, the target position (x, y, z) is converted into an angular axis description (θ1, ..., θn) according to the mechanical structure of the machine. The angular axis description defines a series of equally timed position/velocity commands for each axis. Any timing differences between the axes will result in reduced accuracy of the machine. Consider the two-axis example shown in Figure 4. The target path of the machine is described by a set of (x, y) coordinates. Delays cause timing errors in the y-axis command, which ultimately results in an irregular actual path.

In some cases, the effects of fixed delays can be minimized with proper compensation. More critical, however, is the inability to compensate for variable and unknown delays. Additionally, variable delays cause the control loop gain to change, making it difficult to tune the loop for optimal performance. It should be noted that delays anywhere in the system will cause inaccuracies in machine precision. Therefore, minimizing or eliminating delays as much as possible will improve productivity and end-product quality.

Figure 4. Effect of timing delay on position accuracy.

The traditional motion control approach is shown in the upper part of Figure 5. The motion controller (usually a PLC) sends the position command (θ*) to the motor controller through the real-time network. The motor controller consists of three cascaded feedback loops, including an inner loop that controls torque/current (T/i), a middle loop that controls speed (ω), and another loop that controls position (θ). The torque loop has the highest bandwidth and the position loop has the lowest bandwidth. Feedback from the factory is kept local to the motor controller and is tightly synchronized with the control algorithm and pulse width modulator.

Figure 5. Traditional (top) and emerging (bottom) motion control topologies.

With this system topology, the axis synchronization between the motion controller and the motor controller is achieved through the position command value, but the correlation with the I/O (feedback and PWM) synchronization of the motor controller only makes it a problem in very high precision applications such as CNC machining. The position loop usually has a fairly low bandwidth and is therefore less sensitive to I/O synchronization. This means that the node synchronization performance at the command level is usually acceptable even if the network and I/O are in different synchronization domains.

While the control topology shown in the upper part of Figure 5 is common, other control partitioning methods are also possible, such as implementing the position and/or velocity loops on the motion controller side and transmitting the speed/torque command values ​​over the network. The recent trend in the industrial field is to move to a new partitioning method, that is, all control loops are transferred from the motor controller to a powerful motion controller on the network master side (see the lower part of Figure 5). The data exchanged on the real-time network are the voltage command (v*) of the motor controller and the plant feedback (i, ω, θ) of the motion controller. This control topology, implemented by a powerful multi-core PLC and a real-time network, has many advantages. First, the architecture is highly scalable. Axes can also be easily added/removed without worrying about the processing power of the motor controller. Second, because both trajectory planning and motion control are done in the same central location, it can improve accuracy.

The new control topology has drawbacks as well. The control algorithm is removed from the motor controller, so tight synchronization of code execution and I/O is lost. The higher the bandwidth of the control loop, the more problematic the loss of I/O synchronization becomes. The torque/current loop is particularly sensitive to synchronization.

Moving faster control loops to the motion controller creates a requirement for synchronization all the way from the network host to the motor terminals. The general idea is to synchronize the I/O of all axes with the network so that they all operate in one synchronization domain. Figure 6 shows an I/O event scheduler located between the network controller and the motor controller. The main function of the I/O event scheduler is to generate sync/reset pulses for all peripherals to keep them synchronized with the network traffic. The I/O event scheduler takes the frame sync signal, which is derived from the local clock of the network controller, and outputs the appropriate hardware trigger signals for all I/O that must be synchronized with the network.

Figure 6. The I/O scheduler binds synchronization domains together.

Each I/O has its own set of timing/reset requirements, which means that the I/O event scheduler must provide customized trigger signals for each I/O. Although the requirements of the trigger signals are different, they still have some common rules. First, all trigger signals must be referenced to the frame synchronization. Second, there is a delay/skew associated with each trigger signal. This delay is related to the inherent delay of the I/O, such as the conversion time of the ADC or the group delay of the sinc filter. Third, there is the I/O response time, such as the data transfer from the ADC. The I/O event scheduler understands the timing requirements of each I/O and continuously adjusts the trigger/reset pulse based on the local clock. An overview of the principle of generating each output pulse of the I/O event scheduler is shown in Figure 7.

Figure 7. The I/O scheduler generates trigger pulses.

In most networked motion control systems, the frame rate and frame synchronization rate are equal to or lower than the PWM update rate of the motor controller. This means that the I/O event scheduler must provide at least one, and possibly multiple, trigger pulses per frame period. For example, if the frame rate is 10kHz and the PWM rate is 10kHz, the I/O event scheduler must provide 1 trigger pulse per network frame, and similarly, if the frame rate is 1kHz and the PWM rate is 10kHz, the I/O event scheduler must provide 10 trigger pulses per network frame. This is equivalent to the frequency multiplier in Figure 7. A delay time tD is applied to each synchronization pulse to compensate for the inherent delay of each I/O. The last element of the I/O event scheduler is intelligent filtering. There will be some traffic jitter on every network. The filter reduces the jitter of the trigger pulses and ensures that the rate of change of the frame synchronization frequency is limited.

An example timing diagram for PWM synchronization is shown in the lower half of Figure 7. Note how the frame sync frequency is a multiple of the PWM frequency and how the I/O trigger signal jitter is reduced in this example.

Figure 8 shows an example of a recommended synchronization scheme that has been implemented and tested in a networked motion control system. The network master is a Beckhoff CX2020 PLC connected to a PC for developing and deploying PLC programs. The real-time network protocol (red arrow) is EtherCAT.

Figure 8. Implementation of the synchronization scheme.

The motor controller mainly uses ADI's fido5200 and ADSP-CM408. The combination of the two provides a highly integrated chipset for network-connected motor drives.

The fido5200 is a real-time Ethernet multiprotocol (REM) switch with two Ethernet ports. It provides a flexible interface between the host processor and the industrial Ethernet physical layer. The fido5200 includes a configurable timer control unit (TCU) that implements advanced synchronization schemes for various industrial Ethernet protocols. Additional features such as input capture and square wave signal output can also be implemented with the help of dedicated timer pins. The timer input/output is kept in phase with the local synchronization time and therefore also with the network traffic. This makes it possible to synchronize not only the I/O of a single slave node, but also the slave nodes in the entire network.

The REM switch chip has two Ethernet ports, so two Phys (PHY1 and PHY2) can be connected. This topology supports both ring and line networks. However, in this lab setup, for demonstration purposes, only one slave node is used and only one Ethernet port is active.

The REM switch communicates with the host processor via a parallel memory bus, ensuring high throughput and low latency.

The host processor used to implement the motor controller is ADSP-CM408. It is a dedicated processor based on the ARM ^® Cortex ^® -M4F core for implementing control and application functions. The processor includes peripherals that support industrial control applications, such as timers for PWM inverter control, ADC sampling, and position encoder interfaces. In order to synchronize all peripherals with the network, a flexible trigger routing unit (TRU) is used. The TRU redirects the trigger signals generated by the TCU of the fido5200 to all timing-critical peripherals on the ADSP-CM408. These peripherals include pulse width modulators, sinc filters for phase current measurement, ADCs, and absolute encoder interfaces. The principle of synchronous I/O is shown in Figure 9.

Figure 9. Generating synchronization events for I/O.

In Figure 9, notice how the I/O event scheduler is implemented using both the TCU on the REM switch chip and the TRU on the motor control processor. In other words, the functionality is implemented by two integrated circuits.

The motor controller feeds back the phase current and rotor position of the three-phase servo motor. The phase current is measured using an isolated ∆-ADC and the rotor position is measured using an EnDat absolute encoder. Both the ∆-ADC and the encoder are directly connected to the ADSP-CM408 without any external FPGA or CPLD.

The PWM switching frequency is 10 kHz and the control algorithm is executed once per PWM cycle. As described in this article, the TCU provides a synchronization pulse to the ADSP-CM408 once per PWM cycle.

A photo of the experimental setup is shown in Figure 10. To illustrate the synchronization capabilities of the system, the PLC was set to run a program task that lasted 200μs. The task time also determines the frame rate on the EtherCAT network. The motor controller runs in PWM mode and has a control update period of 100μs (10kHz), so synchronization pulses need to be generated at this rate. The results are shown in Figure 11.

Figure 10. Implementation of the synchronization scheme.

Figure 11. Generating synchronization events for I/O.

The Data Ready signal indicates when the REM switch is providing network data to the motor control application. The signal is asserted every 200μs, corresponding to the EtherCAT frame rate. The PWM Sync signal is also generated by the REM switch to synchronize the motor controller's I/O with the network traffic. Since the PWM period is 100μs, the REM switch schedules two PWM Sync pulses per EtherCAT frame. The bottom two signals in Figure 11, HSPWM and LSPWM, are the high-side and low-side PWM of one of the motor phases. Note how the PWM signals are synchronized with the network traffic.

Real-time Ethernet is widely used in motion control systems, and some protocols can achieve time synchronization with an accuracy of less than 1μs. However, synchronization only involves data communication between the network master and slaves. Existing network solutions do not include motion control I/O synchronization, which limits the achievable control performance. The synchronization scheme proposed in this article can achieve full synchronization from the network master to the motor terminal. Due to the greatly improved synchronization performance, this scheme can significantly improve control performance. This scheme can also provide seamless synchronization across multiple axes. Axes can be easily added and the synchronization can be customized to a single motor controller.

The synchronization is based on an I/O event scheduler that sits between the network controller and the motor controller. The I/O event scheduler is programmable in real-time and at high speed and can be tuned to minimize jitter/frequency variation effects. The proposed scheme has been validated in an experimental setup and the results are presented. The communication protocol used in the experiments is EtherCAT. However, the proposed scheme is applicable to any real-time Ethernet protocol.

ADI website updated and upgraded again