Why are my discrete controllers not identical

I am simulating a simple closed loop speed controller for a DC motor in Simulink.

I have a continuous PI controller working just fine.

I have then discretized the continuous controller and implemented it in two different, but equivalent ways, and it seems that the two discrete implementations provide different results, even though they are supposed to be equivalent.

Both discrete controllers are obtained by the same discretization method (Tustin), but one is implemented as a single discrete transfer function, whereas the other is implemented as a sum of the P and I parts individually.

The attached model contains all setup in the InitFcn callback, and illustrates both the continuous controller as well as both of the discrete controllers.

The "Decomposed Discrete Control Structure" tracks the continuous controller reasonably well, whereas the "Discrete Transfer Function Control Structure" has large deviations, and is even unstable for longer sample times. Conversely, the issue is resolved for faster sample times.

[Birdman]

Can you export this model to R2017a and then share again?

[Morten Juelsgaard]

Sure, here you go - Thanks for looking into my problem

Answer 1

[Morten Juelsgaard]

I figured it out, and the answer is of course that the two discrete implementations are in fact not equivalent, although the difference is subtle.

The "Discrete Transfer Function Control Structure" is implemented as a purely discrete controller since all control processing is handled by the discrete transfer function, including sampling of the error signal.

The "Decomposed Discrete Control Structure" is however in fact a hybrid controller: Since there is no collective sampling of the error signal, the porportional branch is maintained as a continuous contribution to the control action, and only the integral contribution is discretized.

In order to render both discrete controllers equivalent, a sampling of the error signal must be introduced in the "Decomposed Discrete Control Structure", prior to calculating either P or I control actions. This could be done e.g. by a "zoh" block right after calculating the error.

Answer 2

[Birdman]

Hi Morten,

The issue with your controller design was challenging. But I think I have managed to solve it.

Firstly, we need to look at your closed loop system response for your C controller which has Kp=0.5 and Ki=15. With this controller, we need to see how fast the system behaves. Therefore, we need to look for RISE TIME of the closed loop system. It is 0.0088 seconds. Now, in this situation, I would like to make some recall about sampling frequency. According to the Nyquist rule, if you do not want to missample the signal you are observing, you need to choose a sampling frequency which is 15-20 times greater than the signal. In this situation, since the rise time for your controller is 0.0088 seconds, you need to divide this value to at least 15, at most 20. This means, you need to choose a sampling time less than 0.00044 seconds in order not to lose the original signal. Therefore, when you increase the sampling rate(for instance 0.0001 seconds), the discrete time controller works well.

Hope this helps. Make sure to change your sampling rate to less than 0.00044 seconds, or redesign the controller. But in command line, make sure to check the step response characteristics every single time in case that your signal is too fast.

[Morten Juelsgaard]

Thank you very much for your efforts - I completely agree with your observations!

What I was really hoping to learn is why the two discrete implementations differ, since they are completely identical (on paper at least)?

Why does it matter how the discrete controller is implemented when the discretization method is the same?

That is, why does it matter whether the discrete controller is implemented as a single transfer function, or as a sum of the discretized P and I components separately - The underlying difference equations are supposed to be exactly the same?

[Walter Roberson]

Nyquist only requires sampling at twice the rate of changes, but sampling even further can help clarify whether your signal is really at the rate you think it is.