Friday Math Quiz Revisited

kamenges

Member
Join Date
Nov 2002
Location
Green Bay, WI
Posts
4,331
Last Friday Peter got this thread going about PID tuning:
http://www.plctalk.net/qanda/showthread.php?t=36407

One of the things that came up pretty quick is that mathematically you can make any two pole system that is open loop stable as responsive as you want with a PD controller and still keep it stable. Most of us realized that this doesn't happen is real life. Sooner or later you will get the gains so high that the system will become unstable. There are definite causes of this, not the least of which are control system output saturation, actuator saturation and discrete processing update rates.

So one logical question is how do we find that point? Given things like update rate and maximum output how do we know how far left we can put our poles?

I'm getting snoozy. Have a good night everyone.

Keith
 
Good question

In the example I posted last week
ftp://ftp.deltacompsys.com/public/NG/Mathcad%20-%20T0C1-PID%20CTM%20NG.pdf
the PID update periond was 0.01 seconds. At this sample rate I could move the poles to -65. At -70 the control output would start to oscillate. At 0.001 second the poles could move to -90 or -95 before the control output would oscillate.

Another crucial factor is feed back resolution. If the gains are very high then a one count error can cause the control output to saturate. In the applications I am involved with it is the feed back resolution that is the most important factor. Our controllers normally work at 0.5 or 1 msec updates. The following is a .pdf that I made to show that a 300 pulse encoder would adversely affect the performance.
ftp://ftp.deltacompsys.com/public/PDF/Mathcad%20-%20t1p1%20pid%20mrplc.pdf
One can see that having more counts per revolution is better.

Dead time can be a killer to. I was surprised to find how little dead time will make such a big difference.

Extra unmodeled poles. If the closed loop poles are moved to the left near or beyond the unmodeled poles then these poles will add to the phase delay which will adversely affect the response.

I can elaborate more but now I am going to have a beer and watch TV and possibly kill some zergs. I was thinking about what would make a good Friday night quiz. Now Keith has started one I can save my idea for another week. Good going Keith.
 
After a day of watching gradeschool basketball I figured I'd check back in on this. Oh, woe is me. I must really like some esoteric stuff.

So let's take these one at a time. Scan time. I think it's safe to say that the pole location I am shooting for can't have a time constant faster than my scan time. However, it doesn't need to be much faster the way it looks. In Peter's example he lost it at a pole location of -70. This equates to a time constant of 0.014. The scan time was 0.01. So is it safe to say that the scan time is one hard limit?

Feedback resolution. More is better in this case, for the reason Peter pointed out. However, if I have a specific feedback resoultion how do I equate that to a maximum pole location? Is this just a pure gain versus output thing? For example, if one feedback count per scan converted to engineering units times the gain produces some percentage of the maximum control system output this becomes the maximum gain? Given that we may be able to back-calculate pole locations.

Dead time. I'm guessing I can't have a pole farther left than the time constant equivalent of the delay. This would become a hard limit. Is it that simple?

Unmodeled poles. This is a tough one. However, I suspect if you makeit this far you will probably be pretty happy with the performance you are seeing. But that's just a guess.

Keith
 
This the Friday and Saturday night Peter quiz.

kamenges said:
After a day of watching gradeschool basketball I figured I'd check back in on this. Oh, woe is me. I must really like some esoteric stuff.

So let's take these one at a time. Scan time. I think it's safe to say that the pole location I am shooting for can't have a time constant faster than my scan time. However, it doesn't need to be much faster the way it looks.
What? The scan time is MUCH faster than the time constant which is 1/pole

In Peter's example he lost it at a pole location of -70. This equates to a time constant of 0.014. The scan time was 0.01. So is it safe to say that the scan time is one hard limit?
Yes, but that is under ideal conditions. I am updating the .pdf file to include the un modeled poles as if the load is connected to a flexible shaft.

Feedback resolution. More is better in this case, for the reason Peter pointed out. However, if I have a specific feedback resolution how do I equate that to a maximum pole location? Is this just a pure gain versus output thing?
You can't directly

For example, if one feedback count per scan converted to engineering units times the gain produces some percentage of the maximum control system output this becomes the maximum gain? Given that we may be able to back-calculate pole locations.
Yes, but that percentage seems to change on the system and the model.

Dead time. I'm guessing I can't have a pole farther left than the time constant equivalent of the delay. This would become a hard limit. Is it that simple.
Not so but the response tends to degrade at that point. I learned a trick from the controlguru guys as to how to take dead time into consideration in transfer functions. Basically it involves using a Taylor's or Pade's approximation. The trick allowed me to calculate PID gains that take dead time into account. Since the approximation is only an approximation the response does tend to degrade as the dead time gets longer. I have not done any analysis on what factors, besides dead time, affect the response the most. The controlguru site uses IMC ( internal model control ) methods which are very simple compared to the pole placement methods. My formulas for calculating the PID gains for a SOPDT system stretch across the page but they work.

Unmodeled poles. This is a tough one. However, I suspect if you makeit this far you will probably be pretty happy with the performance you are seeing. But that's just a guess.

Keith
I am working on a Mathcad worksheet now that adds two imaginary poles at a higher frequency. This would simulate a un-modeled flexible shaft between the motor and the load. I am still using the original PID gains. This will simulate the effect of the un modeled poles or flexible shaft on the response. What I am finding is that controller update time plays a very significant part.

I will post what I have found tomorrow.

This is an edit. I added a link to a .pdf file that shows the calcualtions for a SOPDT system. I delibrately set the closed loop time constant to a value less that the dead time to show the response. If the closed loop time constant is longer than the dead time the response looks a lot better.
ftp://ftp.deltacompsys.com/public/NG/Mathcad%20-%20t0p2%20OD%20DT%20ISA.pdf
Notice that the PID equations stretch across the page.

The same worksheet when the closed loop time constant is 1.5 times the dead time.
ftp://ftp.deltacompsys.com/public/NG/Mathcad%20-%20t0p2%20OD%20DT%20tc=7.5%20ISA.pdf
 
Last edited:
You guys are definitely going faster than I am.
Peter, I tried to make Scilab script and to verify your results about feedback resolution. Since Scilab doesn't have trunc function I used this: floor(x1(i-1)*res)/res.
I'm unable to see the difference between res= 4000 and res = 40000. If I change res to 40 then the difference is obvious.
I don't believe I made mistake somewhere, but...
Code:
   //Position system => G = K*a / (s*(s+a)); because it is type 1 system
   //Initial conditions:
   clear all
   clc
   u = [0 0]; //control output
   err = [0;0;0]; //error vector
   dp = -3; //desired 3 pole (critically damped response) 
   
   K = 3; //plant's gain
   a = 6.283; //corner frequency
   
   T = 0.01; //sample time
   A = [0 1; 0 -a]; //state space representation, A and B
   B = [0; K*a];
   
   I = eye(2,2); //identity matrix
   Ad = [0 0; 0 0];
   Bd1 = [0 0; 0 0];
   for i =1 : 9
   	Ad = Ad+A^i*T^i/prod(1:i);
   end
   
   Ad = Ad+I;
   
   for i =1 : 9
   	Bd1 = Bd1+(A^i*T^i/prod(1:i+1));
   end
   Bd = (Bd1+I)*B*T;
   
   Ki = -dp/(K*a); //integral gain
   Kp = 3*dp^2/(K*a); //proportional gain
   Kd = (-3*dp-a)/(K*a); //derivative gain
   Kerr = [Ki*T+Kp+Kd/T, -Kp-2*Kd/T, Kd/T]; //PID gains vector
   
   res = 4000; //feedback resolution
   
   time = 6; //simulation time is 6 sec.
   
   n = 1:time/T;
   r = sin(2*3.14*n*T); //desired response (target);
   
   x1 = [0; 0];
   x2 = [0; 0];
   for i = 3:time/T
   	err(i) = r(i)-floor(x1(i-1)*res)/res;
   	u(i) = u(i-1) +Kerr(1)*err(i)+Kerr(2)*err(i-1)+Kerr(3)*err(i-2); 
   	u = max(min(u, 10),-10);
   	x1(i) = Ad(1,1)*x1(i-1)+Ad(1,2)*x2(i-1)+Bd(1)*u(i);
   	x2(i) = Ad(2,1)*x1(i-1)+Ad(2,2)*x2(i-1)+Bd(2)*u(i);
   end
   
   plot(T:T:time, u);
   plot(T:T:time, x1,'r');
   plot(T:T:time, x2,'c');
   
   legend('Control output','Position','Velocity') ;

How trunc function works in Mathcad?
 
Last edited:
Pandiani, the formula for Kp is wrong. I also set the time to T=0.001 for the update time. The shorter the update time the more critical the resolution is.

I am making a new directory on my FTP site.
ftp://ftp.deltacompsys.com/public/Scilab/
I will put code in there when I feed it is ready.

Pandiani, the csim function will make simulations easier. The problem is that I haven't seen how one includes the limits. If I can't figure that out I will try to write a general subroutine for doing simulations. This way the wheel doesn't need to be reinvented.

In any case you did things the hard way. Scilab can mulitply matrices so you can do
x(n+1)=A*x(n)+B*u(n);

I need to learn Scilab much better too.
 
Yes, you're right. I didn't calculate Ki correctly, I forget to put -dp^3 instead -dp. Also desired pole is different then yours.
This is OK now...
Code:
//Position system => G = K*a / (s*(s+a)); because it is type 1 system
//Initial conditions:
clear all
clc
u = [0 0]; //control output
err = [0;0;0]; //error vector
dp = -2*3.14*10; //desired 3 pole (critically damped response) 

K = 3; //plant's gain
a = 6.283; //corner frequency

T = 0.001; //sample time
A = [0 1; 0 -a]; //state space representation, A and B
B = [0; K*a];

I = eye(2,2); //identity matrix
Ad = [0 0; 0 0];
Bd1 = [0 0; 0 0];

for i =1 : 9
	Ad = Ad+A^i*T^i/prod(1:i);
end

Ad = Ad+I;

for i =1 : 9
	Bd1 = Bd1+(A^i*T^i/prod(1:i+1));
end
Bd = (Bd1+I)*B*T;

Ki = -dp^3/(K*a); //integral gain
Kp = 3*dp^2/(K*a); //proportional gain
Kd = (-3*dp-a)/(K*a); //derivative gain
Kerr = [Ki*T+Kp+Kd/T, -Kp-2*Kd/T, Kd/T]; //PID gains vector

res = 40000; //feedback resolution

time = 6; //simulation time is 6 sec.

n = 1:time/T;
r = sin(2*3.14*n*T); //desired response (target);

x1 = [0; 0];
x2 = [0; 0];
for i = 3:time/T
	err(i) = r(i)-floor(x1(i-1)*res)/res;
	u(i) = u(i-1) +Kerr(1)*err(i)+Kerr(2)*err(i-1)+Kerr(3)*err(i-2); 
	u = max(min(u, 10),-10);
	x1(i) = Ad(1,1)*x1(i-1)+Ad(1,2)*x2(i-1)+Bd(1)*u(i);
	x2(i) = Ad(2,1)*x1(i-1)+Ad(2,2)*x2(i-1)+Bd(2)*u(i);
end

plot(T:T:time, u);
plot(T:T:time, x1,'r');
plot(T:T:time, x2,'c');

legend('Control output','Position','Velocity') ;
 
I think I need to put some context around my responses.

One unspoken criteria is that we can design a critically damped system, that is n number of identical real poles in the left half-plane.

A second point is that the 'hard limits' I talk about are not necessarily the exact pole locations. They would be, however, absolute limits on the pole locations. Even in a perfect world they couldn't be violated.

Finally I am assuming the use of standard pole placement techniques given an LTI system.

For example, in the case of scan time, even in a perfect world where all other factors would allow me to keep moving the poles farther left, I can't go any farther than -1/ScanTime. Nothing I have seen so far would contradict this.

In the deadtime case, the first PDF show a system that is somewhat controllable. However, that system certainly doesn't have all it's poles on the real axis. The second system certainly looks critically damped but it also has the closed loop time constants longer than the deadtime. So, if we want a critically damped system the CLTC can't be faster than the deadtime.

The feedback point is a bit worrysome to me. But high resolution is pretty cheap these days. The harder part is finding something that will take the frequency.

I have to admit when I was thinking about unmodelled poles I limited my thinking to non-obvious poles that were relatively far left. I didn't consider missing a coupling or not accounting for frame stiffness or something like that, which is actually more likely to happen.

Keith
 
kamenges said:
For example, in the case of scan time, even in a perfect world where all other factors would allow me to keep moving the poles farther left, I can't go any farther than -1/ScanTime. Nothing I have seen so far would contradict this.
Yes, but nromallty the scan time must be 5 to 10 times the plant time constant.

In the deadtime case, the first PDF show a system that is somewhat controllable. However, that system certainly doesn't have all it's poles on the real axis.
That is because I used a simple approximation for exp(-DT*s). This approximation is less accurate as the dead time gets longer.

The second system certainly looks critically damped but it also has the closed loop time constants longer than the deadtime. So, if we want a critically damped system the CLTC can't be faster than the deadtime.
Can't is such an absolute word. What if I use a Smith Predictor or some other observer based control?

The feedback point is a bit worrysome to me. But high resolution is pretty cheap these days.
I like that attitude.
The harder part is finding something that will take the frequency.
That isn't a problem for us. We have a customer that bought a 512,000 pulse encoder. He turned it using a drill and looked at out graphing tool for position, velocity, acceleration and errors. He said the counts got up to 14 million per second before it started to get errors. We don't advertise that high. It is often unrealistic because the encoders can't output a clean square wave at the higher frequency. The high resolution makes it possible to calculate the acceleration accurately to use with feed forwards.


Pandiani, look at the tricks.
Code:
//Position system => G = K*a / (s*(s+a)); because it is type 1 system
//Initial conditions:
clear all
clc
u = [0 0]; //control output
err = [0;0;0]; //error vector
dp = -2*3.14*10; //desired 3 pole (critically damped response) 
K = 3; //plant's gain
a = 6.283; //corner frequency
T = 0.001; //sample time
A = [0 1; 0 -a]; //state space representation, A and B
B = [0; K*a];
C=[1,0];
// Convert to discrete state space
// S1=syslin('c',A,B,C)
// S2=dscr(S1,T)
// [Ad,Bd,Cd,Dd]=abcd(S2)
[Ad,Bd,Cd,Dd]=abcd(dscr(syslin('c',A,B,C),T));
Ki = -dp^3/(K*a); //integral gain
Kp = 3*dp^2/(K*a); //proportional gain
Kd = (-3*dp-a)/(K*a); //derivative gain
Kerr = [Ki*T+Kp+Kd/T, -Kp-2*Kd/T, Kd/T]; //PID gains vector
res = 40000; //feedback resolution
time = 6; //simulation time is 6 sec.
n = 1:time/T;
r = sin(2*3.14*n*T); //desired response (target);
for i=1:2
  x(:,i)=[0;0];
  u(i)=0;
  err(i)=0;
end
for i = 3:time/T
  x(:,i)=Ad*x(:,i-1)+Bd*u(i-1);
 err(i) = r(i)-floor(x(1,i)*res)/res;
 u(i) = u(i-1) +Kerr(1)*err(i)+Kerr(2)*err(i-1)+Kerr(3)*err(i-2); 
 u(i) = max(min(u(i), 10),-10);
end
plot(T:T:time, u);
plot(T:T:time, x(1,:),'r');
plot(T:T:time, x(2,:),'c');
legend('Control output','Position','Velocity') ;
 
Originally posted by Peter Nachtwey:

Yes, but nromallty the scan time must be 5 to 10 times the plant time constant.

Just to clarify, do you mean the time constant of the physical system itself ot the time constant(s) of the closed loop transfer function after the PID gains are applied? I'm guessing the latter but I've been known to be wrong.

Originally posted by Peter Nachtwey:

Can't is such an absolute word. What if I use a Smith Predictor or some other observer based control?

I must be claravoyant. I almost modified my last post to include the 'no observers' stipulation. I figired you would bring that up. But I thought I'd let it go since it is a reasonable next step if you have delay issues.


Originally posted by Peter Nachtwey:

That is because I used a simple approximation for exp(-DT*s). This approximation is less accurate as the dead time gets longer.

So am I to assume from this that if you used a more accurate approximation of deadtime and using nothing more than a standard PID controller (that means no observers) you could plase the CLTF pole farther left than the delay time equivalent time constant?

Originally posted by Peter Nachtwey:

He said the counts got up to 14 million per second before it started to get errors. We don't advertise that high. It is often unrealistic because the encoders can't output a clean square wave at the higher frequency

Now that's impressive, on both sides.

Keith
 
kamenges said:
Just to clarify, do you mean the time constant of the physical system itself ot the time constant(s) of the closed loop transfer function after the PID gains are applied? I'm guessing the latter but I've been known to be wrong.
You are right. I was sloppy. The update period must be 5-10 faster than the minimum of the closed loop time constants and the open loop time constants.

I must be claravoyant.
You have probably been exposed to more complicated motion systems than most.

So am I to assume from this that if you used a more accurte approximation of deadtime and using nothing more than a standard PID controller (that means no observers) you could plase the CLTF pole farther left than the delay time equivalent time constant?
I think so. It would be a good thing for Pandiani to investigate when he goes for his PhD some time in the future. You can see the formulas for the PID gains are messy enough as they are. Finding a more accurate solution is not the way to go because the formula would be such a mess that no one would use it. It is better to reduce the dead time by threatening the designers that they must hold their breath that long, or use an observer/Smith Predictor.

A few years back I saw the www.controlguru.com site and noticed that the process people had a way of taking the dead time into account. I asked about this and the answer was quite simple but if made my calculations quite messy as you can see. I have no need of this in a motion control program. The ZOH ( zero order hold ) is a big enough problem.

I should lose my motion control merit badge and be excluded from the priesthood of the PID. I forget ZOH!!!!

ZOH is a mini deadtime of one udpate period. This can normally be ignored but the Ackerman method of calculating gains takes the ZOH into account. As the sample period gets larger the PID gains calculated using the Ackermann method decrease. Again, because this too is just an approximation the poles don't stay on the negative real axis. I also have a text book that shows the effects of ZOH as a function of ZOH divided by the open loop time constant.

Most motion systems do quite well with a update time of 1 millisecond. I have a small clipper test system in the warehouse right now with cycle time of 16 milliseconds. This is extreme. The cycle time must be down at the 125 microsecond level.

Now that's impressive, on both sides.
Keith
What is. I know you weren't commenting on the clipper. I could show a video but the clipper moves so fast that it is just a blur with normal video devices. I think we have a 5000 frame per second video camera to capture the motion but mostly we just use our graphs. The high speed video shows how the clipper flexes with the g forces applied.
 
Originally posted by Peter Nachtwey:

It is better to reduce the dead time by threatening the designers that they must hold their breath that long...

Now that would be fun. Or for the shorter time constant systems they could hold a match under their palm.


Originally posted by Peter Nachtwey:

What is. I know you weren't commenting on the clipper.

I was referring to the encoder frequency. Many of the devices I deal with start taking a digger just over 200kHz for an input, if I'm real lucky. Many take a hurl much lower than that. Encoders will many times start dying out at about 350kHz. Then again I've never investigated resolutions in the hundreds of thousands of counts before. If you are going to provide that resolution you most likely need to be able to drive it. But as you said, it doesn't take long for parasitic capacitance to really degrade the signal unless you are extremely careful.

But I think the clippler would be pretty cool to see. A 16msec cycle is pretty freakin' quick.

Keith
 
kamenges said:
But I think the clipper would be pretty cool to see. A 16msec cycle is pretty freakin' quick.
It can't be seen on a normal video and is just a blur to the human eye. It is clipping away out in the warehouse. We are trying to get to 100 million cycles before the motors give out. We are running 16 clips a second to keep the duty cycle low. If we ran it continously the drive would over heat and stop. I will see about getting a graph. I am not directly involved in that project.

BTW, I like the idea of the match for short time dead times. That would separate the good mechanical engineers from the poors one quickly. This gets back to my "It is not designed unless there is a transfer function stamped on it" philosophy.

Keith do you try the Scilab files?
 
Originally posted by Peter Nachtwey:

Keith do you try the Scilab files?

No I haven't. I have a copy of SciLab downloaded but I haven't done much with it yet. I know I should. I just haven't gotten around to using it yet.

Keith
 

Similar Topics

Just for fun, no PLC application that I can see... What are the next 2 values in this series... 1, 3/2, 11/6, 25,12, ...
Replies
12
Views
3,904
Pauly's5.0's thread on PID gain tuning brought up an interesting issue. The derivative gain or time constant can be adjusted to dampen the system...
Replies
23
Views
10,733
Ok everyone, I should be able to do this, but it is eluding me today. I have been asked to change a servo axis such that it has a much slower...
Replies
22
Views
9,195
Retirement Milestone It’s been an amazing 42 year trip. I have had great fun, seen amazing technologies, met good friends, learned something new...
Replies
36
Views
7,367
I usually can find what answers I need in the archives but thought I'm tired, it's been one of those weeks and I could not find the answer last...
Replies
1
Views
1,914
Back
Top Bottom