Nyquist plot disagreeing with the unity step response of the closed loop

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:

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):

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

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.

• I am not seeing that problem in WolframAlpha. – Suba Thomas Dec 13 '19 at 22:22
• @SubaThomas did you try simulating the same closed loop function? What did you get? – Daniel Tork Dec 14 '19 at 19:26
• 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. – Suba Thomas Dec 15 '19 at 0:03
• @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. – Daniel Tork Dec 19 '19 at 14:36
• I need more than a comment to explain what is going on. I will post an answer. – Suba Thomas Dec 19 '19 at 15:59

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.


s = tf('s')
l = 10(s+1)(s+2)/((s−3)(s−4))
pzmap(l/(1+l))
step(l/(1+l),40)

• 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. – Daniel Tork Dec 13 '19 at 19:03

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}]


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

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


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]


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]


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]


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.

• 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. – jDAQ Dec 19 '19 at 21:09
• @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? – Suba Thomas Dec 19 '19 at 22:50
• 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. – jDAQ Dec 19 '19 at 23:26
• 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))) – Daniel Tork Dec 20 '19 at 13:42
• 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. – Suba Thomas Dec 20 '19 at 15:03