Update Times


Thread Starter

Tom Bullock

When it comes to specmanship, the frequency with which the servo is updated ranks high among those specifications that are not well understood. Is 2 milliseconds OK? What advantage is there in going to 200 microseconds or 20 microseconds? First, we must be clear on what is being updated. Is it the position command, the position feedback, the position loop, the velocity loop or the current (which equates to torque) loop? Let’s start by talking about the position command. There are a variety of algorithms used within the control to generate a path for each axis. These algorithms can be linear/circular interpolation, leader/follower, cam following, registration, etc. The result of these calculations is that each axis command register gets a new number every time the calculation is made. If one were to plot the position of the command register for one of these axes as a function of time, it would look like a flight of stairs where the height of the step is the distance that axis must move in one update period. As an example, if the update time for that calculation is one millisecond and the axis is being commanded at 600 inches per minute (IPM), this becomes 10 inches per second or .01 inches every millisecond. The riser on the staircase will be .01 inches and the run will be one millisecond. The ideal servo command would be the straight line generated if the update time became infinitesimally small. The disturbance from the ideal servo command is a saw tooth wave with a height of .01 inches and a frequency of 1000 Hertz. How will the servo react to this command disturbance? For the majority of industrial machinery, the servo bandwidth will be in the range of 2 to 10 Hertz. The highest bandwidth would be most apt to respond to this disturbance, so let’s consider a 10 Hertz bandwidth. Once the bandwidth of a servo is exceeded, the output rolls off at a 40 DB per decade rate or a ratio of 100 to 1 for each decade increase in frequency. Since the 1000 Hertz disturbance is two decades from the bandwidth, the roll off will be 10,000 to 1. This would reduce a .01 inch disturbance to .000001 inches or 1 micro-inch. Hardly a problem. Unless you are dealing with some extremely high velocities and some pretty hot servos, it appears that a 1 millisecond update suffices for command generation. There is one caveat, however. If you are using the command register to trigger some event, be sure the 1 millisecond delay is not of consequence. It is usually advisable to trigger events off the actual feedback as will be discussed next. When using encoders as the feedback device, the position feedback register is updated every time a pulse comes along, so it stays in sync with the actual machine position. When using resolvers, most digitizing techniques update the feedback register once per carrier frequency cycle. Thus if the analog sine wave used to drive the resolver is 1 Kilohertz, the feedback register will be upgraded once per millisecond. This is why most suppliers are using carrier frequencies in the 2,000 to 10,000 Hertz range now days. This assures updates in the 500 to 100 microsecond arena. There are some resolver-to-digital (R/D) converters that employ techniques to overcome this problem. Also when triggering events off the position, don’t forget that there will be a servo error unless feedforward techniques or PID is used. Also, since these features are sometimes switched in and out, it is safer to simply trigger events off the feedback, rather than the command. How often the servo loop itself is updated is another concern. And, there are three loops to worry about. Updating a loop means subtracting the feedback from the command to generate the error and manipulating that error with digital or analog lead/lag filters, PID, notch filters, feedforward, or any other loop feature that may be available. There has been a rough rule of thumb that the update rate of a servo loop should be at least 10 times the bandwidth. For a position loop with a 10 Hertz bandwidth, this suggest an update frequency of 100/second or 10 milliseconds per update. For a velocity loop with a 100 Hertz bandwidth, the update would be every one millisecond. For a current loop bandwidth of 1,000 Hertz, the update time would be 100 microseconds. This helps explain why the PWM chopping frequencies are often in the 10 Kilohertz range for those who are doing the current loop digitally. It also explains why many are doing the current loop in an analog fashion due to the high burden on the computer time when the loop has to be served 10,000 times per second. Usually, in the specification, only one update time is given. That number usually means the time elapsed between position loop closure calculations. And, with today’s technology, it is not hard to achieve 1 millisecond, which most vendors are meeting or beating. With industrial machinery, this is adequate, especially if the current (torque) loop is analog. Those vendors who are in the 100 microsecond arena are either playing the specmanship game or are doing the current loop digitally (or maybe a bit of both). As computers continue to get faster, the update times will get shorter and shorter, but it will be hard to see any further significant changes in servo performance with industrial machines. Tom can be reached at Industrial Controls Consulting, a division of Bull’s Eye Marketing, Inc. See them at www.bullseyenet.com, or phone (920) 929-6544 or email: [email protected].

Servo performance won't get much better with decreased update rates?

Here is one for you to chew on . . . . I wouldn't have believed it had I not set it up and tested it myself.

I set up a cascaded PID loop using a Delta Tau PMAC Motion controller configured for 442 usec PID loop update rate. Command was generated by a function generator and sent into the PMAC via a 16 bit analog input.
Outer PID loop: position feedback from an LVDT also fed into the PMAC via a 16 bit analog input. (CMD = function generator, feedback
is a hydraulic cylinder with LVDT)
Inner PID loop: position feedback from a LVDT on the voice coil actuated spool valve. CMD = error from outer loop.

We futzed around with tuning and got a respectable system response of about 500 Hz.

We then changed the update rate on the servo loops to 50 usec. We could now push the system and get reasonable performance to 2kHz at the actuator generating in excess of 45 G's on the accelerometer mounted to the cylinder.

The actuators used were designed by TEAM Incorporated in Burlington Washington and the amplifier used to drive the spool was an
analog design. I then wrote a motion program that allowed us to play songs on the actuator. You could do some pretty major shaking of the
floor in the lab at the lower frequencies and shake your fillings loose in the mid range, once above 300 Hz, the stroke was somewhat limited and you began to feel like you were inside an acoustical speaker.

Loop update rates played a significant roll in getting the performance that we achieved.

As motion components improve in bandwidth, machine designs will change to take advantage of them.

Best Regards,

Ken Brown
Applied Motion Systems, Inc.
Voice 360 686 1133
Fax 360 686 1166
Yes, these are truly remarkable results.
For industrial machinery, the inertia is usually the determining factor in bandwidth. The hottest hydraulic system we've ever seen on a real machine is about 15 Hz. A typical servo valve has a 50 Hz bandwidth which is another limiting factor. Hydraulic motors have a very low inertia, but even adding a Thomas coupling without the load will bring it to the point where the mechanical resonance is less than 50 Hz.
What you are achieving would not be practical on industrial machinery. If it were, the update rate would, indeed, need to be much better
than the Motion Control article indicated. My point is that motion vendors are trying to convince engineers who never see bandwidths over 5 Hz that they still need 200 microsecond update times in the position loop.
Thanks for your input.
Hi Tom: I came across some of your articles. They are very informative and very clear. Thank you. I was reading the above article about update times and I have a question regarding external events on the control system. I am not sure if my previous understanding of bandwith was in error, so I was hoping that you could set me straight. I assume that when you refer to bandwith, you are referring to the closed loop bandwith. In my experience, if the system has noise which can get into the amplifiers, this can cause the motor to oscillate. If the motor is capable of responding to these high frequencies and the closed loop bandwith of the servo is lower than the noise, the control system cannot mitigate the affects of the noise. Also, noise (or external disturbances to the system) can affect the feedback sensor in the same manner. If the sensor is not sampled often enough, the servo cannot mitigate the affects of the disturbances. I always thought that the system (including motor, sensor, load), should be tested for their open loop gain - if the system response to a sine wave can be detected using the feedback sensor, then it is possible for it to become unstable due to external events. Therefore, I would want to have the sample rates set to 4-10x this frequency. Is my thinking goofed up? Thank you - Greg Zimmer
Greg, The ability of a servo to withstand load disturbances is called stiffness and is discussed in one of the other papers here on the BULL! page. The disturbance must be within the bandwidth of the servo before the servo can begin to suppress it. The bandwidth is the point at which the open loop gain is 1 or the closed loop gain is .7071. If the disturbance is higher than the bandwidth of the servo, it may be suppressed using notch filters, but you need to know the frequency. If the servo has a natural resonance that is causing the oscillation, it will be a particular frequency that can be dealt with in the notch. If the disturbance is caused by some odd ball discontinuity in the load so the frequency is not predictable, you have a problem. Hope this helps. Tom

Alex Ruderman

I would like to draw the attention to current sampling aspects in digital current loop.

Digital 3-phase sinusoidal current loop performance is generally lower than that of an analog one. Since AC motor sinusoidal phase currents are distorted by PWM current ripple (PWM noise), straightforward sampling with PWM frequency may produce noisy current measurements that will deteriorate overall closed loop performance.

Any PWM noisy motor current samples filtering - analogue or digital based on oversampling - introduces averaging delay undesirable for high performance / bandwidth applications.

For high-speed closed loop operation, current phase delay causes fundamental current increase. Sinusoidal current distortion also produces additional (harmonic) loss.

There is a sampling with PWM frequency (1X sampling) technique that under some realistic assumptions theoretically eliminates PWM caused current ripple.

High performance operation requires further refinements. It is clear that all the switching points in-between current sampling instants are calculated in advance and don’t account for motor current change on PWM period.

The concept of digital PWM current loop performance improvement might be as follows:

- to obtain more PWM ripple-free "clean" current samples;
- to use this additional information for switching instants "dynamic" calculation (adjustment).

As for "clean" samples, it is possible to characterize (additional to 1X sampling) current PWM ripple-free time instants and PWM noise (additive corrections). 2X sampling theory shows the way to double (and even to quadruple!) the count of PWM noise free motor current samples.

Based on motor current sampling, this theory allows:
- motor inductance identification;
- DC bus voltage (cycle-by-cycle) monitoring;
- low cost one current sensor (in DC link) scheme successful implementation.

[email protected]