Help with PID for motorised fader

[IanB]

It's always advisable to set derivative to zero unless proven to be needed.

I don't like this kind of grossly incorrect generalizations. When PID controller is used as a generic control component without conversion (e.g. integrating, taking derivatives) of inputs and outputs, what terms are needed depend on what is being measured and what is being controlled. So the roles, mental expectations of what P or I or D do are not actually fixed!

Thanks for the detailed comments. I was also thinking yesterday that driving a motor speed to achieve a position is indeed an integrating process, since the speed of the motor is integrated to give the position of the output shaft. Controlling an integrating process with a PID controller is challenging and does require a different approach to tuning. I totally agree with you there.

Fortunately, not many processes are pure integrators like that. Liquid level in a tank is another one, where the tank level is the integrated value of the flows in and out.

That said, you do often need some integral action even on an integrating system, since the accumulated integral action produces an offset or bias on the controller output. Without integral action you need to manually set the bias on the controller output. For example, if your normalized PID output runs from 0 - 100% and you are controlling motor speed on a positioner, then you might bias it so that 50% output corresponds to zero speed, 0% corresponds to max reverse, and 100% corresponds to max forward. Or you would express the PID algorithm in absolute engineering units, where the error is expressed in millimeters of deviation and the controller output is expressed in revolutions per minute (or something). But doing this causes every control loop to have different scaling and it becomes harder to apply rules of thumb to the magnitude of the tuning constants. Consequently PID loops often normalize their inputs and outputs in a range from 0 to 1 (0% to 100%) to fit the range of the associated A to D and D to A converters.

Coming back to the opening point about generalizations. I have been tuning process control loops in the chemical process space (flows, levels, pressures, temperatures, etc.) for about 40 years, and I would say in over 90% of cases the D term has been set to zero. If a generalization is something that is true most of the time, then in the process engineering space my comment fits. Where you can take me to task is that there are many other domains where PID control is used, in mechanical and electrical systems, for example. And in those domains, derivative action may be much more relevant.

So, you got me. Point taken.

[Siwastaja]

Also, DC motors won't move at all below a certain PWM percentage threshold, where this threshold is will often vary with PWM frequency too. I found I had to have code after the PID that boosted any non-zero value up to that threshold (in whichever directionnwas appropriate), this tended to lead to some oscillation about the stopping position, though it settled to the correct position over time.

Implementing current feedback and using current as controller parameter (speed PID loop controls current setpoint, not PWM duty directly) will tremendously help.

From current setpoint, you go to PWM with another feedback loop (current measurement --> PWM duty%), but that loop can be PI (without D) and tuning it is much more forgiving.

[MrAl]

It's always advisable to set derivative to zero unless proven to be needed.

I don't like this kind of grossly incorrect generalizations. When PID controller is used as a generic control component without conversion (e.g. integrating, taking derivatives) of inputs and outputs, what terms are needed depend on what is being measured and what is being controlled. So the roles, mental expectations of what P or I or D do are not actually fixed!

Thanks for the detailed comments. I was also thinking yesterday that driving a motor speed to achieve a position is indeed an integrating process, since the speed of the motor is integrated to give the position of the output shaft. Controlling an integrating process with a PID controller is challenging and does require a different approach to tuning. I totally agree with you there.

Fortunately, not many processes are pure integrators like that. Liquid level in a tank is another one, where the tank level is the integrated value of the flows in and out.

That said, you do often need some integral action even on an integrating system, since the accumulated integral action produces an offset or bias on the controller output. Without integral action you need to manually set the bias on the controller output. For example, if your normalized PID output runs from 0 - 100% and you are controlling motor speed on a positioner, then you might bias it so that 50% output corresponds to zero speed, 0% corresponds to max reverse, and 100% corresponds to max forward. Or you would express the PID algorithm in absolute engineering units, where the error is expressed in millimeters of deviation and the controller output is expressed in revolutions per minute (or something). But doing this causes every control loop to have different scaling and it becomes harder to apply rules of thumb to the magnitude of the tuning constants. Consequently PID loops often normalize their inputs and outputs in a range from 0 to 1 (0% to 100%) to fit the range of the associated A to D and D to A converters.

Coming back to the opening point about generalizations. I have been tuning process control loops in the chemical process space (flows, levels, pressures, temperatures, etc.) for about 40 years, and I would say in over 90% of cases the D term has been set to zero. If a generalization is something that is true most of the time, then in the process engineering space my comment fits. Where you can take me to task is that there are many other domains where PID control is used, in mechanical and electrical systems, for example. And in those domains, derivative action may be much more relevant.

So, you got me. Point taken.

Hi,

There is a good rationale for using the D part.  It's almost like you are giving the system an advanced look into the future so it knows where it is heading even before it gets there.

I am sure you know that a 'slope' is an increase or decrease in some quantity that keeps changing over time.  That's almost always (maybe always) used in conjunction with a coefficient.  For a simplified example:
y=m*t+b
Here the 'm' is the slope.  Having the slope involved with the value of 'y' it gives us a sort of glimpse into the future about where 'y' will be after the next increment of time 't'.  That gives the rest of the system a little more knowledge about how the control will work.  'm' is not usually a constant though because it changes over time.  Once the system starts to stabilize, 'm' becomes a lower value, and thus has less and less influence on the system final value.

I think a really good example, although a little too complicated to discuss here maybe (or maybe not), is a buck circuit where we measure the current in the inductor.  That's like measuring the derivative.  If we use that information, we can control the output even faster than just measuring the output voltage, which of course is mandatory with a regular buck circuit.

The advantage is in a system that would otherwise have objectionable overshoot if we tried to control it faster (a very typical control theory problem).  Since the system has a sort of advanced knowledge of what will happen next, it can almost 'foresee' the overshoot before it happens because the derivative is a high value at that point, and if it was already a low value it would 'know' that the overshoot will not be that bad so less dv/dt compensation would be required.  That allows it to use that to help to prevent the overshoot from happening or at least not as bad as it would have been.

Not all systems are going to need this because a lot of them can be controlled without objectionable overshoot, such as in overdamped systems.  There's no problem there so the D part probably would not do anything or would actually cause more overshoot.

That's more or less theory of the control of systems which allows us mostly to understand the workings of systems, but a more practical way to adjust the coefficients uses fuzzy logic.  There's a good article on it on the web somewhere but I'd have to find it again.  A search should turn something good up though.  Probably something like, "Using fuzzy logic to adjust a PID control system".

[IanB]

The reason you don't find derivative action used so much in the process industries is that it common to tune control loops quite slowly and give them a damped response. One reason for this is that the processes being controlled are often quite non-linear, so a tuning which is fast but stable in one region of operation could become unstable in a different region due to the non-linearity. Very often control engineers will be happy if control loops drift slowly to the set point, and there is rarely a need for a super aggressive response. It should remembered that everything comes at a cost, and if you put tight control on the measured variable, you will have a lot more movement of the manipulated variable, and this may have its own consequences. For slow, damped, control action, PI is typically sufficient.

There are of course cases where faster and tighter control is needed, and in that case a more analytical approach to tuning will be used, and all three PID terms may be included.

Another characteristic of derivative action is that it can react to noise on the measured signal, and process variables can often have noise on the measurement. For this reason, derivative action is almost always combined with a filter in the measurement to remove any high frequency content in the signal.

[IanB]

Out of curiosity, and to illustrate some of the comments made by various posters to this thread in a more concrete fashion, I made a simulation of a motor-driven positional servo with a PID feedback controller.

There is a motor which runs in either forward or reverse direction to move the position of an output actuator, which has a position target set by the controller. The motor is simulated with inertia, so it takes time to respond to changes in speed demand.

All model parameters are dimensionless, and only relative magnitudes have any meaning. There is no reference to actual physical dimensions or units of measure.

Some results from this simulation are attached:

• With only proportional action there is a tendency to overshoot and some oscillation around the target position.
• Reducing the proportional gain can remove the oscillation, but then the control action is slower.
• Introducing derivative action allows the gain to be increased and leads to a much faster control action without oscillation or overshoot.
• Introducing integral action leads to gross overshoot and poor control. It should be left at zero.

[Siwastaja]

There is a good rationale for using the D part.  It's almost like you are giving the system an advanced look into the future so it knows where it is heading even before it gets there.

With this line of thinking, let me once more remind everyone of the existence of feedforward. Use it! Super simple. Can be something as simple as a fourth term off the setpoint, so that the whole equation becomes:

output = Kff * setpoint + Kp * error + Ki * (accumulated error) + Kd * (error - prev_error)

Tune with all P, I, D terms all set to zero, for best possible response from feedforward alone. Then tune the rest as usual.

You can also add stuff like feedforward from setpoint change (Kdff * (setpoint - prev_setpoint).

These things truly look into the "future" - D term still has delay, it has to go through generating an error before it can react.

[IanB]

With this line of thinking, let me once more remind everyone of the existence of feedforward. Use it! Super simple. Can be something as simple as a fourth term off the setpoint, so that the whole equation becomes:

output = Kff * setpoint + Kp * error + Ki * (accumulated error) + Kd * (error - prev_error)

Tune with all P, I, D terms all set to zero, for best possible response from feedforward alone. Then tune the rest as usual.

You can also add stuff like feedforward from setpoint change (Kdff * (setpoint - prev_setpoint).

These things truly look into the "future" - D term still has delay, it has to go through generating an error before it can react.

Surely if error = (setpoint − value), then Kp * error expands to Kp * setpoint − Kp * value, and the feedforward term is already there?

It could also be mentioned that while responding to setpoint changes can be useful in servo (setpoint following) applications, it may be undesirable in regulatory (rejecting disturbances) applications. So many implementations have an option to include or ignore setpoint changes in P and D terms. (In fact, some algorithms may ignore setpoint changes on the D term altogether, since a sudden change in the setpoint would cause a big jump in the output.)

[MrAl]

There is a good rationale for using the D part.  It's almost like you are giving the system an advanced look into the future so it knows where it is heading even before it gets there.

With this line of thinking, let me once more remind everyone of the existence of feedforward. Use it! Super simple. Can be something as simple as a fourth term off the setpoint, so that the whole equation becomes:

output = Kff * setpoint + Kp * error + Ki * (accumulated error) + Kd * (error - prev_error)

Tune with all P, I, D terms all set to zero, for best possible response from feedforward alone. Then tune the rest as usual.

You can also add stuff like feedforward from setpoint change (Kdff * (setpoint - prev_setpoint).

These things truly look into the "future" - D term still has delay, it has to go through generating an error before it can react.

Hi,

It's interesting that you should bring this up, then add PID back into it.
I say this because feedforward control if often used by itself so that might be an interesting topic too.
There are disadvantages though, such as system modeling accuracy.
I might agree that is probably the most future predicter control.

The topic of control theory is rather wide and encompasses a lot of knowledge so there would be many different ways to do this kind of thing.

[MrAl]

The reason you don't find derivative action used so much in the process industries is that it common to tune control loops quite slowly and give them a damped response. One reason for this is that the processes being controlled are often quite non-linear, so a tuning which is fast but stable in one region of operation could become unstable in a different region due to the non-linearity. Very often control engineers will be happy if control loops drift slowly to the set point, and there is rarely a need for a super aggressive response. It should remembered that everything comes at a cost, and if you put tight control on the measured variable, you will have a lot more movement of the manipulated variable, and this may have its own consequences. For slow, damped, control action, PI is typically sufficient.

There are of course cases where faster and tighter control is needed, and in that case a more analytical approach to tuning will be used, and all three PID terms may be included.

Another characteristic of derivative action is that it can react to noise on the measured signal, and process variables can often have noise on the measurement. For this reason, derivative action is almost always combined with a filter in the measurement to remove any high frequency content in the signal.

Hi,

Yes, I had hinted on this with the lines:
"Not all systems are going to need this because a lot of them can be controlled without objectionable overshoot, such as in overdamped systems.  There's no problem there so the D part probably would not do anything or would actually cause more overshoot."

There are so many areas in control theory that could be discussed I doubt we could cover all of them here, thus every reply will be like a microcosm of what can really be done.  I think we've all touched on some of the good ones.