1
\$\begingroup\$

Let us assume that the open loop transfer function of my system is:

\$L(s)=\frac{10(s+1)(s+2)}{(s-3)(s-4)}\$

Also, the system has unity feedback, meaning that the closed loop transfer function is

\$T(s)=\frac{L(s)}{1+L(s)}\$ since \$L(s)=G(s)H(s)\$ and \$H(s)=1\$

Then the Nyquist plot is this:

enter image description here

There are 2 RHP poles present and the plot circles the (-1,0) point 2 times, anti-clockwise. \$Z=N-P\$ where \$N=-2\$ and \$P=2\$ so \$Z=0\$ => Stable System.

And the unity step response is this (for the closed loop):

enter image description here

It looks stable, but if I press on "more time", it looks pretty unstable:

enter image description here

So the Nyquist plot is disagreeing with the unity step response. What is happening?

The transfer function is theoretical in nature, it does not necessarily represent a real system's response. I have taken care to make sure that the unity step response is that of the closed loop transfer function (and not that of the open loop, which is clearly unstable). I used WolframAlpha for all my plots.

\$\endgroup\$
5
  • \$\begingroup\$ I am not seeing that problem in WolframAlpha. \$\endgroup\$ Dec 13, 2019 at 22:22
  • \$\begingroup\$ @SubaThomas did you try simulating the same closed loop function? What did you get? \$\endgroup\$ Dec 14, 2019 at 19:26
  • 1
    \$\begingroup\$ Yes, I tested the step response of the closed-loop system in both Alpha and Mathematica and did not see the issue you are experiencing. \$\endgroup\$ Dec 15, 2019 at 0:03
  • 1
    \$\begingroup\$ @Suba Thomas, you raised a valid point, the way I introduce my transfer function affects the unit step graph. If I take a closed loop transfer function in the form ((s+7)/(s-3))/(1+(s+7)/(s-3)), I get the described noisy and odd behaviour. However, if I first simplify it to (s+7)/(2*s+4) and then put it in, there will be no problem. \$\endgroup\$ Dec 19, 2019 at 14:36
  • \$\begingroup\$ I need more than a comment to explain what is going on. I will post an answer. \$\endgroup\$ Dec 19, 2019 at 15:59

2 Answers 2

3
\$\begingroup\$

Please double check the simulation/plots. That behavior seems way too fast ("noisy") for the dynamics of your system. I tried simulating the closed loop system in Octave and could notice that there is an unstable pole cancellation, but that does not lead to the "unstable" behavior in Octave.

I would say that is a problem in WolframAlpha and not really a control theory thing.

pole zero map of the closed loop system

step simulation of the system


s = tf('s')
l = 10(s+1)(s+2)/((s−3)(s−4))
pzmap(l/(1+l))
step(l/(1+l),40)
\$\endgroup\$
1
  • 1
    \$\begingroup\$ Thank you very much for taking your time to double check my plot! Indeed, other step-response plots confirm that there is a problem with Wolfram Alpha. \$\endgroup\$ Dec 13, 2019 at 19:03
2
\$\begingroup\$

The closed-loop system has a RHP pole and zero. If they are not cancelled, the unstable dynamics can sometimes show up in the output.

This is the result you are seeing from Wolfram Alpha.

((s + 7)/(s - 3))/(1 + (s + 7)/(s - 3));
Grid[{{tfm = TransferFunctionModel[%, s], ssm = StateSpaceModel[tfm]}}]
or = OutputResponse[ssm, UnitStep[t], {t, 0, 20}];
Plot[or, {t, 0, 20}]

enter image description here

If you plot the entire range, you will see that the output actually blows up.

Plot[or, {t, 0, 20}, PlotRange -> All]

enter image description here

If the pole and zero are cancelled then the dynamics is stable.

Grid[{{tfm1 = TransferFunctionCancel[tfm], 
ssm1 = StateSpaceModel[tfm1]}}]
or1 = OutputResponse[ssm1, UnitStep[t], {t, 0, 20}];
Plot[or1, {t, 0, 20}, PlotRange -> All]

enter image description here

To get a clearer picture, do the analysis with the Jordan canonical realization.

ssm2 = Last@JordanModelDecomposition@ssm
or2 = OutputResponse[ssm2, UnitStep[t], {t, 0, 20}];
Plot[or2, {t, 0, 20}, PlotRange -> All]

enter image description here

You can see that the output is stable and well behaved because it depends on just the first state. The second state is unstable and blows up, but does not manifest itself in the output. You can plot the individual state responses and see that the second one does indeed blow up.

sr2 = StateResponse[ssm2, UnitStep[t], {t, 0, 20}];
GraphicsRow[Plot[#, {t, 0, 20}, PlotRange -> All] & /@ sr2]

enter image description here

In summary, it depends on how you realize this transfer function. If the unstable dynamics cannot be cancelled, they will show up somewhere. You may not see it at the output, but things are blowing up internally.

\$\endgroup\$
6
  • \$\begingroup\$ But doesn't that response looks weird for a linear system? It looks more related to numerical errors while calculating the step/impulse than the actual unstable mode showing up. Specially since both poles are real, and they should not lead to those oscillation, which only come up after an almost "settled" response. \$\endgroup\$
    – jDAQ
    Dec 19, 2019 at 21:09
  • \$\begingroup\$ @jDAQ Yes, it's numerical error because the unstable term \$e^{3 t}\$ is not getting cancelled as \$t\$ increases. In Octave are you doing a pole-zero cancellation before simulation or is it done internally. If not, up to how high a value of \$t\$ can you simulate and still see a constant steady-state response? \$\endgroup\$ Dec 19, 2019 at 22:50
  • \$\begingroup\$ I have not tested the limits of the octave model, but I assume it has actually done a model reduction and properly cancelling the pole. And by numerical error, I mean that the unstable mode displayed in the plots is not even a \$ e^{3 t} \$ it is all wavy and high frequency, while taking a lot of time to start being displayed. I have not tried it out in Octave yet, but I wonder what type of rounding errors or simulation errors leads to that behavior, and what value of pole is causing that. \$\endgroup\$
    – jDAQ
    Dec 19, 2019 at 23:26
  • \$\begingroup\$ So you are saying that it's clear that the unit-step response of the output should be stable for all t, but there is something actually unstable within the system? So then even though Wolfram shouldn't put it in the output, it is right to point out that something is unstable elsewhere in the system? (Note: given the closed-loop transf. is ((s+7)/(s-3))/(1+(s+7)/(s-3))) \$\endgroup\$ Dec 20, 2019 at 13:42
  • \$\begingroup\$ Whether it should put it in the output or not is a matter of opinion. If it's not cancelled, there are a bunch of terms that need to simplify to \$\frac{e^{3 t}}{2}\$ and others that need to simplify to \$\frac{-e^{3 t}}{2}\$. As \$t\$ increases these terms become larger and cause loss of precision, and they will not match and cancel each other out at machine precision. \$\endgroup\$ Dec 20, 2019 at 15:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.