Hi! Welcome to our first “explain the CHANGELOG” blog post. We’ve never introduced a CHANGELOG as substantial as the one that’s coming in v4.2, and since it’s such a dramatic improvement to performance, we feel some explanation of the new features and improvements may help.
Our main focus was on improving the overall performance of the SOMANET Servo Node and Circulo (EtherCAT) products. I’ll break down the improvements into four categories, and give an introduction to each.
- Things that boost the torque controller performance
- PWM frequency is selectable and operates with higher efficiencies
- Increased voltage efficiency across motor phases
- Motor position prediction
- Things that improve motion control performance
- Notch filter on the input to the torque controller
- Network synchronization via the EtherCAT distributed clock
- Torque control frequency is now 16 kHz, motion is 4 kHz
- Velocity feed-forward
- New CiA 402 standard features
- Homing modes 33, 34, and 35/37
- Controller supervision
- Profiled modes position, velocity, and torque
- Diagnostics and brakes and more!
- Brake release has been redesigned for vastly improved performance (and selectable switching frequency)
- High resolution data buffer has been made available
- PDO mapping is expanded
- The drive controller can handle 4 kHz cyclic communication
- Support for Nikon A-Format
- Hall and incremental encoders, working together
- Scaled external ADC measurement
- An input counter is supported for slow frequencies (under 8 kHz)
Things that boost torque controller performance
Our method for controlling the torque can be viewed as something of a hybrid of techniques. One such component of this controller is the motor model, used to predict phase currents for a given set of applied phase voltages. Since an accurate estimate of the rotor angle is crucial for efficiency, we predict the angle based on velocity at multiple points in the calculations. This makes the controller even better at computing accurate phase voltages, boosting performance at high speed.
But that’s not all. Since this applied voltage can only be as big as what is available on the bus, we have introduced a technique known as harmonic injection to ‘float’ the neutral point of the motor and apply the maximum phase-to-phase voltages. This boosts the power output by 14 percent!
Okay, so we’re more powerful in all cases, and even more powerful at high speeds, and that’s impressive and it’s time to go home?
Oh no. Given the unique processing capabilities of the SOMANET SoC, we’ve redesigned the PWM generator to reliably allow for lower deadtimes and meet tighter FET driver requirements, which has boosted _again_ the maximum voltage we can apply across the motor phases.
It’s hard to come up with a single number to describe the new controller, but 30% torque improvement is about right. Use your new power for good. Oh, and if you’re controlling a very low inductance motor and it’s getting unreasonably hot, try selecting a higher PWM switching frequency to minimize the current ripple. That’s new too.
Things that improve motion control performance
One thing to note before we jump in here, is that the maximum bandwidth of torque and motion control loops have increased slightly. The torque control cycles increased from about 15 khz to 16 kHz. This will likely have minor noticeable impact, particularly because our current controllers are dead-beat modeled instead of only relying on feedback control. The position and velocity controllers have both been increased from about 3 kHz to 4 kHz. Along with this and some other optimizations surrounding these controllers, it’s worth revisiting the tuning of your axis. You will likely achieve better performance.
EtherCAT performance has also been upgraded to serve requests at 4 kHz, so you can get the data in and out faster.
Timing and synchronization
A typical robot consists of several servo drives controlling a series of axes, and an EtherCAT master that sends incremental position updates to every axis synchronously. This sounds good, but “synchronous” is a bit misleading. Although the commands are indeed being sent at the same time, the servo nodes don’t actually use the data at the exact time they’re received. Why? Because the master and each servo drive have their own clocks! The master may think it’s sending the commands every 1000 microseconds, but in reality, it’s 999.432. The servo nodes may believe it runs the control loops every 333 microseconds, but in reality some of them are slightly faster, and some are slightly slower.
The drift between the nodes isn’t generally an issue until one of the controllers loops right before receiving the next command. Or maybe it loops too slow and misses the previous command. This is an aliasing effect, and the existence of this beat frequency in the execution of synchronous commands causes small but present discontinuities in the command. If your controller is tightly tuned, this will cause noticeable vibration in the response.
Even worse, imagine what happens if the master command contains jitter and doesn’t perfectly send the commands at exactly the same time. This jitter can be dramatically high if the host computer is not a real-time system, but even with very precise systems the jitter can be several microseconds. The effect of this is that when the “beat” occurs (i.e. the command is being sent right at the edge of the execution of the next control cycle), the jitter will cause one command to be received right before the cycle, the next right behind the cycle, and so on, until the edge of the control cycle has drifted further away from the jitter window.
This can make your system behave as if somebody is drumming on your mechanics. To give you a feeling of scale, this could be a full second of drumming every 10 seconds! And it comes entirely from the aliasing effect between the master and servo node internal clocks.
So what do we do about it? We can take advantage of a feature of EtherCAT called the “distributed clock”. This heartbeat signal is generated by the first node in the chain, and is calibrated throughout the EtherCAT network. It provides the master and servo nodes with a reliable tick, accurate to around 15 nanoseconds even in very large networks. The v4.2 release provides drift compensation using this signal. To test it out, hook up the brake output from two nodes to an oscilloscope, disengage the brake, and set a trigger on the rising edge of one signal. You should see the PWM signal from both nodes on the display. Without the distributed clock enabled, you’ll notice that the signal without the trigger drifts in one direction. However, as soon as you enable the clock, the PWM components from both nodes stabilize and the drift is gone!
With the distributed clock enabled, you’ll find it’s easier to achieve tighter controller tuning.
Desired torque value notch filter
If a mechanical system has a disturbance at a particular frequency that finds its way back into the torque command, you may wish to prevent the torque controller from reacting to this. Similarly, if a frequency needs to be avoided to prevent resonance, a notch filter gives you a method for preventing a high level controller from exciting it.
This notch filter is implemented on the input to the torque controller. High level controllers (position or velocity) as well as the Target torque and Torque offset objects are first passed through this filter.
For help tuning this filter, see our documentation.
Velocity feed-forward
The cascaded position controller has two stages; position and then velocity. Since the velocity controller is independent, it’s possible to minimize position following error by priming the input to the velocity controller with a good guess about what the input will be even before the controller has the chance to correct for the measured error. Feed-forward works by analyzing the derived velocity of the position command, filtering it, and then scaling the result by a gain to control how much boost is applied to the velocity command.
This feature is likely to result in less following error without penalty, so some feed-forward is usually desirable. It’s off by default, but our documentation can help you set it up appropriately for your system.
New CiA 402 standard features
Homing support
We’ve introduced homing support, in the form of the three most common modes.
33 – move backwards to the previous single-turn position and set the position to zero
34 – move forward to the next single-turn position and set the position to zero
35/37 – set the current position to zero
See our documentation for details.
Controller supervision
To monitor the health of your machine, some supervision of the control performance is necessary. We’ve added several objects that can help with diagnostics.
See our documentation for details.
Status of the controller
These objects give you a view of the inputs and outputs of the given controller. For example,
- Position demand value (0x6062) – provides the position after passing through predefined limits.
- Position demand internal value (0x60fc) – provides the position after it comes from a profiler and before it enters the controller.
Similarly for velocity and torque:
- Velocity demand value (0x606b)
- Torque demand value (0x6074)
The control effort is the output of the controller for the selected mode. So if you’re in velocity mode, the control effort is the torque target sent to the torque controller.
- Control effort (0x60fa)
Following error
The following error is computed as the difference between the demand value and the actual measured value.
- Following error actual value (0x60f4)
- Following error window (0x6065)
- Following error timeout (0x6066)
This is an excellent indicator of how well-tuned your control system is, but it’s also a good indicator of whether the mechanical system has changed in a significant way. For example, if the following error has started increasing this month, maybe it’s time to re-lubricate or send the axis out for repair.
Target reached
If the actual value is inside of the configured window for a configured period of time, a bit in the Statusword will go high. This window is defined as a region around the target value.
- Position window (0x6067)
- Position window time (0x6068)
- Velocity window (0x606d)
- Velocity window time (0x606e)
- Torque window (0x2014) – both window and time is specified in this record
Even more things!
Profile modes position, velocity, and torque
The firmware now supports trajectory generation on the servo node. This provides the ability to command the drive to a particular position, velocity, or torque with set velocities and accelerations. The standard CiA402 profile definitions are implemented.
See our documentation for details.
Brake release has been redesigned
Pin brakes are released by gently (and quickly) applying a torque to lift the load and relieve the pressure on the pin. The position is monitored to determine if the pin was released, and the procedure stops when it detects this. This whole procedure is much smoother and configurable.
We’ve also introduced a brake mode that allows the master to set the voltage on the 4th phase manually. This allows for different brake release strategies on the master, as well as providing a generic output for anything configured on this phase.
Note that if you were using a certain torque percentage for the release strategy, this parameter has been moved to (`0x2004:9`) Maximum torque. See the documentation for details.
High resolution data buffer has been made available
This one is pretty exciting, though we’re still considering it a prototype of things to come. Most servo drives provide some ability to oversample a couple signals and take a snapshot for several milliseconds or so. After the movement, the data is downloaded and displayed on a graph. It gives the user a view at a small snapshot of the entire motion. But for some applications, this restricted timeframe can be a problem for capturing problematic behavior.
With this feature, we’re introducing a real-time high resolution stream of data. There is now a 1 millisecond buffer of several internal parameters in the object dictionary. Currently, this buffer is composed of the position and velocity sampled at 4 kHz, and two measured phase currents sampled at 16 kHz. To see a very high resolution view at the internals of the controllers, add these parameters to a PDO map and decode them on the fly. This is not yet integrated into OBLAC Drives, but you can decode the data on your own master.
PDO support
The drive now supports dynamic PDO mapping, and the maps have been expanded to provide space for 40 objects. There are four maps: 0x1600 through 0x1603 and 0x1A00 through 0x1A03.
Support for Nikon A-Format
We support Nikon A-Format encoders! All you need is hardware support for half-duplex communication (for example, the Drive 1000 rev E).
Hall and Incremental encoders, working together
Your node can now be configured to work with Hall sensors and an incremental encoder set for commutation. This will allow the axis to skip the index detection procedure at startup (the process for finding the absolute position of the encoder), since the Hall sensors provide this information. Commutation thus gets the startup benefit of the absolute Hall sensors with the increased resolution and performance of an incremental encoder.
Refer to the configuration documentation for details.
Scaled external ADC measurement
Devices such as temperature sensors require some translation between the measured voltage and the output temperature. To support this natively on the drive, we’ve introduced a 5th-order polynomial that can be configured to do this translation.
Object 0x2038 External scaled measurement contains the objects necessary for setting it up. See our documentation for more details.
An input counter is supported for slow frequencies (under 8 kHz)
The object named 0x2040 Input counter will count up based on a clock signal attached to an input. This can be useful for getting speed estimates for low-frequency signals, such as those from fans or pumps.
See our documentation for details.
Conclusion
This doesn’t begin to scratch the surface of all the improvements behind-the-scenes. Motion Drive v4.2 is faster, synchronous, and precise.
Let us know what you think! As always, let us know if you run into trouble at support@synapticon.com. or on our contact page.
We’re here to help.
Author: James Beck, Software Engineering Manager at Synapticon
