# Constant Gain Controller affecting settling time??

#### Slicko

Joined Nov 11, 2008
7
Right... this should be a simple question, but I just can't seem to solve it. I have a simple unity gain control system with a constant gain controller in the forward channel, before the plant.
basically like the figure below;

with H(s)=1 as it's unity gain feedback, and the controller having a constant gain Kc.

the transfer function for the plant is
Rich (BB code):
(K*Km)/(s[R(Js+b)+Km^2])
with K=10, Km=0.5, R=1, J=0.003, b=0.1

I've modelled it in simulink and when simulated it shows that the settling time of the system increases as the gain Kc of the controller is increased. This makes sense as a higher gain causes a larger overshoot and so the signal is obviously going to take longer to settle.

The problem is that whenever I do the maths and calculate everything, I find that according to the equations, the gain Kc of the controller always gets cancelled out and no matter what it equals I get a settling time of 0.069s.
I know the settling time (to within 2% of final value) is defined as 4/ζωn. I've found the closed loop transfer of the system to be
Rich (BB code):
[(Kc*K*Km)/J] / s^2 + [(b+Km^2)/J]s + [(Kc*K*Km)/J]
which gives

ωn = √(KcKKm/J)
and
ζ = [(b+Km^2)/J] / 2√(KcKKm/J)

just looking at these you can see that when multiplied together, the parts containing Kc are simply cancelled out.

What am I doing wrong??

(sorry if there are any mistakes in there i'm writing all the transfer functions from memory, should be correct though)

Last edited:

#### steveb

Joined Jul 3, 2008
2,431
A couple of questions.....

1. How much change do you see in the settling time versus gain Kc?

2. What solver are you using?

3. What accuracy level are you running the solver with?

I don't think the settling time formula is absolutely precise, but it should be very close. My guess is that you are not using enough accuracy with the solver, or the solver is not well suited to the problem. Given that it is a simple system, I think the accuracy setting is more likely to be the problem.

#### Slicko

Joined Nov 11, 2008
7
the settling time is actually around 0.069s when simulated with Kc=10, but goes up to around 0.15s with Kc=50, 0.35s at Kc=60 and goes way passed 1s with Kc=70. Using the Routh-Hurwitz stability test I calculated that the system should become unstable at Kc≈72, which the simulation confirms.

I'm using Matlab/Simulink. It's the first time i've used simulink so i'm not that familiar with all it's options/parameters.

and yeah you're right sorry I should have written the settling time formula as Ts≈4/ζωn.
The point behind this question is i'm trying to answer a problem i've been given and one of the sections states
Rich (BB code):
Is it possible to have the settling time approximately equal to 0.5s by using a constant gain controller?
and what I have so far is the math telling me that it is not possible, as the settling time for this system while using a constant gain controller is always going to be .069s, while Simulink is telling me that a gain of around 63 will produce roughly a 0.5s settling time.

#### steveb

Joined Jul 3, 2008
2,431
OK, I understand.

Something is strange here. If you have a system that can go unstable as the gain increases, then definitely the settling time has to increase as gain is increased. However, the system response equation you show does not have this behavior. A quick check of stability shows no value of Kc produces unstable operation. The transfer function you showed is always stable.

I think that you have implemented a system in Matlab/Simulink that does not correspond to that transfer function.

If you are willing to post the models, I can look at it.

Last edited:

#### Slicko

Joined Nov 11, 2008
7
Ah I've just found the issue. It was a simple issue after all, too many late nights for me I think...

In the section before this problem, the approximation Km/(Ls+R)(Js+b) ≈ Km/R(Js+b) was made due to the electrical time constant (Ls+R) being significantly less than the mechanical time constant (Js+b). I did change this in the simulink model but obviously forgot to save it. It's working as predicted now.