The case of the unstable servo

Most engineers can remember sitting through classes in control theory, when the main topic was how to avoid instability. The problem with these classroom discussions is they tend to be abstract. In the real world, instability is a physical phenomenon.

Instability in a speed-controlled motor system is a case in point. It is actually caused by uncontrolled and unintended motion at the motor shaft. It can happen at low or high frequencies, with the higher frequencies often becoming audible (usually a “growling” sound). This sort of instability comes from excessive gain in the speed controller of the drive.

The gain setting of the speed controller determines how much torque the drive will generate. Consequently, the gain value should be directly proportional to the inertia of the load the motor shaft sees.

Ac-vector drives that implement speed control seldom have instability problems. But vector drives can indeed reach unstable conditions because, in practice, most servo applications that involve positioning are more dynamic than those that only control speed. The more dynamic applications demand higher gains in the speed controller, which increases the chance of instability.

There are several factors that can contribute to the likelihood of a drive experiencing instability. Besides excessive gain in speed controller, they include use of a lower-resolution feedback device on motor (i.e., resolver or pulse encoder); and gearing backlash and mechanical “decoupling” of the load from the motor.

Drive engineers are generally taught to tune a speed controller with the step-response method. This involves running the motor typically at 10 to 20% speed and introducing a step change in the speed set point of 5 or 10%. The step change creates a disturbance that the drive must respond to. By tracing how the drive responds to the step change, engineers can measure the degree to which the drive overshoots the new speed set point and how quickly it gets back to a steady-state speed value of under ±0.5%. Many engineers are taught to gradually raise the speed controller gain until they see signs of instability in the step response. Then they reduce the gain slightly to avoid the instability.

The mistake often made is to run this test only at one speed or only at speeds above 10% of full speed. In some cases, the system will seem stable at these test settings but will, in fact, be unstable at lower speeds. Many machines let servodrives run at zero or near-zero speed and may remain at this low speed prior to starting production. This is the point where instability or “growling” is sometimes reported.

Also consider that drive tuning typically takes place during commissioning when the machine is new and the mechanics are tight. Over the next few months, most such machines run for hundreds of hours and their mechanics loosen up. The drive wasn’t tuned for this additional compliance in the mechanics during commissioning. This explains why instability often arises several months after the machine is installed.

Dealing with adaptive gain
The term adaptive gain refers to an automatic lowering of the controller gain at low speed and an automatic rise in gain as the motor rpms increase. Most servodrives offer this feature.
The gain value for a speed controller is often denoted K_p. When adaptive K_p is enabled, K_p has the ability to change with motor speed.

Adaptive K_p can help avoid the problem of eventual instability at near-zero speeds. It is particularly helpful for motors that might be enabled at extremely low speeds and run at crawl or homing speed. And most machines do not produce material at low motor speeds, so why keep the gain high unnecessarily? That said, if the servomotor always accelerates to a high rpm immediately after it is enabled, then adaptive gain may not be as critical.

Another factor that can cause instability at low speeds is a speed-feedback device that has too little resolution. Resolution is defined as the ability of a feedback device to detect small changes in angular position of the motor shaft. Servomotors do not usually use pulse encoders for speed feedback. The low-resolution feedback device of choice is often a resolver. Systems using high-resolution feedback generally opt for an optical encoder, also called a sin/cos or incremental encoder.

Some may disagree with the classification of a resolver as a low-resolution device because it has an analog output which, in theory, should have infinite incremental values for one revolution. This is true, but the reality is that today’s servodrives process analog signals with analog-to-digital converters in order to use the positional information. This limitation results in most resolvers having less than 10,000 increments/rev.

In contrast, sin/cos optical encoders transmit 2,048 sine waves and 2,048 cosine waves for every revolution. Drive electronics typically samples each wave at a high rate, effectively processing more than 1,000,000 increments/rev. This factor of 100 increase in resolution eases the task of tuning the motor.

To understand why resolution is critical, it is helpful to review how a speed controller works. The speed controller is typically a proportional-integral controller whose input is the difference between the speed set point and actual speed (encoder) values. The output of the speed controller is an instruction that generates the torque set point. The set point determines how much force the motor shaft will exert on its load. Therefore, the torque command to the motor is directly proportional to the difference between actual speed and the speed set point. To smoothly control the motor load, the input to the speed controller should never instantly have a large value.

Today’s servodrives have speed controllers that update in the once-every-100-to-200-µsec range. For a specific example, assume a 125-µsec speed controller on a motor running at 30 rpm. That means the motor shaft will spin 0.023° in 125 μsec. A typical resolver with resolution of 10,000 pulse will put out 27.78 pulses/degree, or 0.625 pulses/125 μsec. In other words, the resolver may not emit a pulse during a given speed scan update.

Thus, at this low speed, resolver feedback might register no difference in angular position over consecutive scans of the speed controller. To the controller, it looks as though the drive has not moved over the previous 125 µsec. This causes the speed controller to immediately generate a large output to try to reduce the perceived speed difference at its input.

During the next scan of the controller, there is an incremental change. The controller then reduces its output because there is less perceived difference in commanded and actual speed. It should be obvious how this behavior could cause erratic movements at this low speed. To avoid this undesired consequence, the engineer tuning the drive must keep the gain of the speed controller quite low. A low gain slows the response time of the controller. Then when two scans happen before the encoder registers one incremental change in shaft position, the controller delays its response long enough to see the new pulse during its next scan.