How do I reverse the effect of an integral block?

Quick summary of the system I'm designing. This is a model of a PID speed controller for a motor driving a lead screw. The problem comes with modelling the encoder which reads the rotor position, and differentiates it to get the speed for the feedback loop.

The reason I'm calculating the speed like this is because it's a more accurate representation of the actual system.

The controller works fine when I take the speed feedback directly (before the "convert to rotations" integral block), but for some reason when I take the output of the integral block and differentiate it, it completely breaks the controller.

Shouldn't taking the derrivative of the position give me the speed at that point, or at least a close approximation of it? Is there something fundamentally wrong that I am doing with this setup?

[Sam Chak]

@Janith Wijekoon

Can you measure and compare the two signals marked by the red dots? Show the graph later.

[Janith Wijekoon]

There you go:

For comparison, this is what the same signal looks like if I take out the derivative block and get my feedback right after the (1/60) gain block :

[Sam Chak]

Hi @Janith Wijekoon

Thanks for showing the comparison.

Without the derivative block, you are measuring the angular speed directly. If you look closely at the 1 second (horizontally stretched image), you can see the original output is a high-frequency oscillatory signal that quickly dies down in that split second. This effect is caused by the setpoint jump at 1 second and the selection of the 'aggressive' PID gains.

Naturally, when the derivative block is used on the angular position signal to recover the angular speed, the high-frequency oscillatory signal will cause the excitation effect in the derivative block, and amplified by the 60-Gain block. This excitation effect is sufficient to cause a degradation in the motor performance, if it isn't sufficient to destabilize the motor system.

[Janith Wijekoon]

I see. that makes sense, thanks. So potential fixes would be :

1. Tuning the PID to have a smoother approach to the reference
2. Running the feedback signal through some low pass filter

Answer 1

[Paul]

Hi Janith

Are you sure the encoder is a pure differentiator? Even if it is, the simulation is likely to have problems with the Derivative block in the loop for reasons already pointed by @Sam Chak. If you haven't already, read the doc page for the Derivative block for more discussion and caveats.

To address the problem, maybe consider:

a) Make the maximum step size of the solver smaller than it is now.

b) Replace the Derivative block with a Transfer Function block of the form

s/(s/wh + 1)

where wh is greater than 5 - 10 times the oscillation frequency (in rad/sec) of the transient at the set point jump (when feedback back the integrator input). This approach will result in very high frequency pole in the loop, make sure to control the solver step size appropriately.

c) If allowed in your problem, consider adding a low pass filter at the output of the PID controller with bandwidth high enough so as not to have much impact on the low frequency portion of the control loop, but with bandwidth low enough to attenuate that oscillation.

d) As @Sam Chak implied, perhaps revisit the PID parameters.

Or maybe a combination of the above.

[Janith Wijekoon]

Hi Paul,

I believe the differentiator block is actually a filtered derivative of the form s/(cs+1), and c is set to inf by default. So adding in fix (b) should be easy enough.

I do intend on representing the encoder as a quantizer followed by a discrete time derivative block, but when this issue came up I switched to a continuous time derivative instead to make debugging the issue earlier.

Should I really reduce the solver step size to get rid of this issue though? I'm worried that doing that won't prevent this issue from showing up in my actual implementation once I build this thing. I guess that's equivalent to adjusting the frequency at which all my filters and controllers are run at.

Anyway, thanks for the suggestions, very helpful!

[Paul]

The Derivative block is not implemented with s/(cs + 1). Perhaps you're thinking of the derivative control in the PID block, which is implmented that way. If you have the Filter Coefficient in the PID control set too high, that might be causing a very large input to the motor at the set point change. So that's another parameter you can try to tune.

But I think you really should try to avoid that Derivative block in the simulation.

The Derivative block doesn't like large changes in its input, so reducing the max step size of the solver can help in that regard. Keep in mind that your actual implementation has to run on the real system, not a simulation thereof. So the sampling period of the implemented controllers and filters is not really a function of the simulation step size, but rahter the actual dynamics of the real system. The purpose of the simulation is to represent your system to a level of accuracy that's sufficient to allow you to fiigure what the controllers and filters need to be, including their sampling period.

[Sam Chak]

Hi @Janith Wijekoon

Please follow @Paul's suggestion to see if the outcome is improved.

To prevent the setpoint jump, try adding a filter after the reference step input.

Also, instead of using the PID controller, check if using the PI controller works.

If you need to differentiate the angular position signal without applying the filters, then you can also consider using the Robust Exact Differentiator Block.

http://www.reichhartinger.at/

[Janith Wijekoon]

@Paul the derivative block's description says this though.

I've been trying really hard to get this to work with a derivative block but whatever solution I implement doesn't seem to work.

Filtering out the high frequency oscillations from the feedback also seems to break the controller, I'm guesssing because now the feedback doesn't represent what the motor is exactly doing.

Also, I can't filter the output of the PID block either, because that signal just looks like this (when the controller is working properly):

Reducing the step time did get the derivative block to work properly, but it created a whole other problem that I think I'll just make a different post about.

Isn't using a derivative for something like this standard practice, since that is what your encoder and MCU does anyway to read the speed? I'm worried that if I just bypass that and get the speed feedback directly, I'll just run into this exact same issue when I actually implement the controller.

[Janith Wijekoon]

@Sam Chak thanks, I tried using both a filtered step as well as a ramp input instead of a step, it works much better! I should be able to program this thing to only recieve gradual changes in speed as a solution.

[Paul]

Hi Janith,

According to the doc page, that parameter c is only used when the model is linearlized, but it is not used during simulation. Note the phrase "used for linearization" in the dialog box.

I can't say what's standard practice, but I'm pretty sure that using the Derivative block can be problematic in simulation. So even if the encoder truly is an analog differentiator, it may still to be prudent to model it as an approximate differentiator (exactly as can be done for linearization with c)