Adjusting PID for closed loop stepper


Thread Starter



I have a closed loop electronics with encoder to drive a stepper motor in closed loop. That means that the rotor field is always set in dependence of the rotor and an optimal load angle is reached all time.

I implemented speed control with an PID controller. To get the right PID parameters I will increment the P-part until the system begins to oscillate. With the P-part and the oscillating-frequency you can determine the I and the D-part.

But what happened? I always set I and D to zero - only P is incremented. At first, the motor runs fine. Then by the further P-increasing there is a point where the motor turns with the set speed, but begins to grumble. The grumble has a frequency of about 200 Hz.

If I mount a load to the motor and get the new PID parameters, I have the same behaviour. For example, the speed is set to 250 rev/min and the P-part is increased until the grumbling, then the motor rotates with about 250 rev/min with the same superposed frequency of 200 Hz, which generates the grumbling.

I expected that with the load and the too strong P-part, the oscillation is 250 rev/min +- 50 rev/min. But I never reach this high amplitude oscillation. Independent of the load - if the P-part becomes too high, always the 200 Hz grumbling dominates.

Who has experience with this effect? This behaviour is strange and I can't adjust the PID to the controlled system - because the grumbling of the motor dominates and determines the PID values.
Is there a way to eliminate the grumbling?

Robert Scott

Is this a commercial PID controller, or is it a custom software implementation in a PLC or other computer? If it is the later, then it is quite possible that the software is not properly handling arithmetic saturation.

If you are using true floating point representation in all PID calculations, then there is no saturation problem. But if you are using integer or fixed point representations, then you must check that each multiplication or addition does not overflow the range of the fixed point or integer representation. Alternatively, you can perform a careful design analysis to ensure that with the inputs given, there is no possibility of calculation overflow. No matter what limits you assume for the inputs, the integral term is always capable of overflowing if the loop is prevented from closing. So the integral term usually contains an "anti-windup" saturation limit that must be checked as each increment is made to the integral. (Even if calculation overflow is not a possibility, anti-windup is useful so that when the loop is finally allowed to close after being held in a big error state for a long time, it will not overreact with its long-delayed correction).

Robert Scott
Real-Time Specialties
Embedded Systems Consulting
>Is this a commercial PID controller, or
>is it a custom software implementation
>in a PLC or other computer? <

The complete control software is implemented by myself.

>If it is
>the later, then it is quite possible
>that the software is not properly
>handling arithmetic saturation.
> ... <

This is done - an over/underflow will be checked.

>So the integral term usually contains an
>"anti-windup" saturation limit that must
>be checked as each increment is made to
>the integral. <

Anti windup is implemented.

It seems that if I increase the P-Part until the motor grumbles, the grumbling frequency is near the resonance-frequency of the motor-rotor. I made a test: I measured with an oscilloscope the voltage swing of the powerfree motor-taps, if the motor falls of about 1cm height. And I saw that the voltage swing is about 200 Hz. So I suppose, that the grumbling is the result of powering the motor with the resonance frequency of the rotor. This creates an swinging rotor with all the problems described.
I had tried same thing for servo control. Servo was used in position control loop and accepts pulse input from controller. I was varing frequency of output pulses with PID output and faced same problems.

This is obvious because there will be always some error in follwing and PID will try to correct it and yout motor is gumbling. This can be minimised with low pass filter used at pid output it will eliminate high frequency variations in controller output.

Try to add some deadband to PID input if application allowes.
I added a low pass filter at PID input and PID output. The grumbling is minimized. That was a good hint.

Which frequency of PID call do you use at your servo application?

Best regards,

Peter Nachtwey

>Is there a way to eliminate the grumbling?

Yes, keep the rate of change of the pulses smooth. I am not surprised that you are hearing the motor growl because I doubt you are changing the step rate and direction smoothly within the acceleration limits of the motor.

You don't need a full PID. If the motor falls behind then the pulse generator program must compute a new number of pulses to generate. Do not try to make up for slipped pulses all in the same period. The response will be too rough and the sudden speed changes may exceed the acceleration abilities of the motor and load.

You should have a FPGA that allows you change the step rate on-the-fly every update period. The FPGA should allow you to specify fractional number of pulses per millisecond.