Minor Loop Control questions

JCH wrote:
...


...
Success can be its own justification; I don't question your successes. You must understand, though, that if the system cum controller model predicts instantaneous change in the output, it must be deficient in at least one respect, making all of its predictions suspect. A model is only a model, and if one needed to be exact in order to be useful, none would serve. That said, a model with serious departures from even potential reality doesn't deserve much confidence.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Modeling in this context means doing mathematically. The results depend on input data accuracy. If input approximation is 97% accurate then you have a good model.
Let's assume Peter's model is of that quality and there is no further significant loss by using appropiate equipment then it would work very well.
I guess that he proved it.
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
JCH wrote:

Unless I looked at the wrong result, Peter's model predicts no delay between command and response, and allows step changes in the response. The mathematics may be good, but there can be nothing in reality that it models correctly, and precious little that it models adequately.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I think you have us confused. It is JCH that has no delay between the command and the response. It takes my example, in the iterative tuning thread about, 100 milliseconds to reach the first set point.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Peter Nachtwey wrote:
...

You're right; I do. My comments applied to the result of his model.
I apologize for slandering you. :-)
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I think you have us confused. It is JCH that has no delay between the command and the response. It takes my example, in the iterative tuning thread about, 100 milliseconds to reach the first set point.

I have delay between manual step and target value! This will reduce forces (acceleration).
Have a look at Page 1 and 2: http://home.arcor.de/janch/janch/_news/20070422-nachtwey / 1 g ~ 10 m/s^2 = 10000 mm/s^2
Force F = m * a a = acceleration m = mass
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
JCH wrote:

Well then, I'm completely confused and slandered everyone. Wjose system gain was k/(k+1) or some such?
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

It is hard to keep tract of what JCH is doing. I took me a couple of posts to figure it out.
See this link http://home.arcor.de/janch/janch/_news/20070417-nachtwey /
You can see that the actual ( magenta v2 ) follows the target ( red u ) almost exactly. JCH generates a filtered target position using a low pass filter. The transfer function is v2/u. JCH justs inverts the F1(s) ( the plant ) to get F2(s) ( the controller ) so the product is always 1. Now one can simplify the transfer function to 1/(1+1/k). If all the terms are mulitplied by k the transfer function is k/(k +1). This implies there is no lag time so a step change in the target position would cause a step change in the actual position. This is not possible without having a way of adding and removing energy instantly.
In JCH's last post he has done something different but it isn't clear what. At least it is more realistic.
I think JCH should look at this. Deadbeat and Dahlin controllers are somewhat related to what JCH is trying to do. http://lorien.ncl.ac.uk/ming/digicont/control/digital3.htm
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

It is hard to keep tract of what JCH is doing. I took me a couple of posts to figure it out.
See this link http://home.arcor.de/janch/janch/_news/20070417-nachtwey /
You can see that the actual ( magenta v2 ) follows the target ( red u ) almost exactly. JCH generates a filtered target position using a low pass filter. The transfer function is v2/u. JCH justs inverts the F1(s) ( the plant ) to get F2(s) ( the controller ) so the product is always 1. Now one can simplify the transfer function to 1/(1+1/k). If all the terms are mulitplied by k the transfer function is k/(k +1). This implies there is no lag time so a step change in the target position would cause a step change in the actual position. This is not possible without having a way of adding and removing energy instantly.

Jan:
Peter, my last posting shows: Velocities, acceleration. Your actuator should be able to accelerate the mass like you can accelerate your car. The acceleration graph may look suspicious, but it is not.
Example: Starting from 0 to 1 m in 1 s the velocity after 1 s is 1 m/s. And acceleration is 1 m/s^2 immediatly (looks like a step). You need 1 N if mass is 1 kg.
I showed the acceleration in: http://home.arcor.de/janch/janch/_news/20070422-nachtwey /
That is all realistic. If you have mass to move you can calculate the maximum force F_max=m*a_max) looking up acceleration from the graph. If you haven't the necessary force built in your system will fail working properly.
The velocities look also plausible. That means realistic. Why should it be impossible to move mass like that if the force is available.
Maybe you show us your velocity and acceleration. These are the first and second derivatives. I guess MATLAB can do that.
Notes:
1) If you have no process and no controller you can move the mass directly as shown with u, v2, v2', and v2''. (u = v2)
2) In Page 2 I used a more smoothing filter: T^2*u'' + 2*d*T*u' + u = w, d=1, T=0.055.
3) E.g., if demands are 'extremly high' (d=2, T=0.002) then you must have the force for accelerating ~ +/-25g. That shows technical limits.
See also http://home.arcor.de/janch/janch/_news/20070423-nachtwey /
--
Regards/Gre http://home.arcor.de/janch/janch/menue.htm
Jan C. Hoffmann eMail aktuell: snipped-for-privacy@nospam.arcornews.de
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I would make three Bode plots. I did. One for the original transfer function. One for the new minor closed loop and one for the new closed major and minor loop. If you find the poles of the minor closed loop you will see there is one around -6.6 and it is what is slowing down your response. You can change the minor loop parameters and see how the minor loop Bode plots and comple transfer Bode plots change.
That is a comment. I don't know what you are trying to do but I would make the bandwidth of the minor or inner loop higher by changing the minor loop feedback.
Is this home work? If not why have a minor loop unless there is another feedback device?
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

Yes... this is homework. I made the 3 bode plots you suggest--- and they tell the sluggishness story. I think I understand--but would like confirmation that: a minor loop feedback controller cannot possibly be used to ajdust the velocity constant of the given (or in general ANY) plant. True or False?
Thanks Peter.
Bo
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

The feedback gain can change the velocity constant. Look at the steady state gain of just the minor loop as s->0. As you have it now the gain is 1 as s->0. Change the 0.125*s to just 0.125. That changes the minor loop gain to 0.888 and the velocity constant down to 0.888.
I make motion controllers for a living. I never worry about the velocity constant. I use the symbols Kv and Ka for velocity and acceleration feed forward not velocity and acceleration constant. I think most people use feed forwards to reduce the following error while moving and accelerating. It would be interesting to hear if others use the velocity constant in real applications. It is good review for me too.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

Yes. But if you change 0.125 to 0.0125 or 1.25 (ie don't remove any s terms), it seems that velocity constant cannot be changed. We asked the prof about this and although we had communication barriers in getting him to understand our questions, he did seem to confirm that a gain-only change in minor feedback loop cannot affect the Kv/Ka of the system. What is not very clear to the entire class is, what advantages/disadvantages are incurred by minor loop feedback as opposed to series compensation?

Glad to hear it. I worry my questions are too basic/fundamental sometimes. Good to know they force some cobb-webs out of {not only my} mind. :)
Thanks for your help. This'll be 2 controls courses down.. next controls class on the plate is Modern Control EE701 this fall.
Bo
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
bo wrote:

After looking up "minor loop" on the web, I checked not one, but two of the references on my shelves -- neither of them refer to them. That's a relief.
What I did see showed what I've been taught to call "inner loops". At least one of the web references didn't distinguish between a trivial inner loop (like my first example) and a significant one (like my third example) -- this is a huge difference when you're dealing with uncertain plants or nonlinear ones.
I'd be interested to know if there's any technical difference between the terms "inner loop" and "minor loop".
I'm not sure if this illuminates anything for you, but if you have a loop of the form
_ .--------. _ .--------. / \ | | / \ | | ------>| + |-->| |-->| + |-->| |----o------> \_/ | | \_/ | | | A '--------' A '--------' | | | | | | .--------. | | | | | | | '-----| |----o | | | | | '--------' | | | '----------------------------------------' (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
then the "minor loop" compensation isn't much but a fancy way of adding feed-forward.
What _will_ fundamentally change the behavior of the loop is either if you have a different sensor, or if you're closing a loop around some intermediate output.
So this, if you are (say) measuring rate with a gyro, or acceleration for the inner loop, then position with the outer:
_ .--------. _ .--------. / \ | | / \ | | ------>| + |-->| |-->| + |-->| |----o------> \_/ | | \_/ | | | A '--------' A '--------' | | | | | | .--------. | | | | | | | '-----| |----o | | | | | .--------. '--------' | | | | | '-----| |-------------------------' | | '--------' (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
This gets you better information about the plant behavior, and lets you deal with it sensibly.
The other one that causes a fundamental change is this one:
_ .-----. _ .-----. .-----. / \ | | / \ | | | | ------>| + |-->| |-->| + |-->| |---o--->| |--o------> \_/ | | \_/ | | | | | | A '-----' A '-----' | '-----' | | | | | | | .-----. | | | | | | | | | '-----| |---' | | | | | | '-----' | | | '-----------------------------------------------' (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
Here we have some intermediate plant (like a valve being controlled in position) that we're commanding with our "main" controller output so that we have a well-defined input to our "main" plant (like a tank). This sort of loop is seen so often that the inner loop is often buried in another diagram (or in some 3rd-party manufacturer's product). It improves performance by making the inner plant/actuator behavior much more predictable, often in a way that can't be done just by monitoring the "main" plant's output.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: bo wrote: : > I designed a lead-lag series compensator controller for my plant that : > looks like : > : > Gc = 10(1+s/58.4)(1+s/100)/(1+s/8)(1+s/700) : > : > my plant is : > Gp = 100/s(1+s/100)(1+s/1000). : > : > I successfully simlutate and prove a stable design with the goals of : > velocity constant = 1000 : > phase margin = 50 deg. : > : > Now, I am converting this controller to a minor loop controller and : > have successfully suimulated it and verified stability of the minor : > loop and overall plant---but I have some questions that I don't : > understand: : > : > 1) by basing the design on the previously determined Gc, do I need to : > worry about velocity constant? (ie will the minor loop feedback have : > to be re-adjusted to guarantee kv00)? : > : > 2) my original gaincrossover was calculated to be about 140 rad/s. : > Unexpectedly, the Bode plots for the minor loop compensator move the : > gain crossover from 140 to about 60. Is this to be expected? if so, : > why? : > : > My matlab/simulink seem to indicate all is OK--I'm just bugged by the : > fact of gain crossover frequency moving so far to the left and giving : > a more sluggish step-response than the supposed equivalent series : > lead-lag compensator? : > : > My web searches have yields nothing useful on minor loop : > techniques/comparisons. : > : > My approximated minor feedback block is: : > : > : > 0.0125s/(1+s/58.4) and is applied around the (1/(1+s/100)) term of the : > plant. : > : > Comments? : > : > THanks, : > : > Bo : : After looking up "minor loop" on the web, I checked not one, but two of : the references on my shelves -- neither of them refer to them. That's a : relief.
I had seen inner loops refered to as minor loops before. I too refer to them as inner loops.
: I'd be interested to know if there's any technical difference between : the terms "inner loop" and "minor loop".
I haven't seen anything that indicates they are not the same. : : I'm not sure if this illuminates anything for you, but if you have a : loop of the form : : _ .--------. _ .--------. : / \ | | / \ | | : ------>| + |-->| |-->| + |-->| |----o------> : \_/ | | \_/ | | | : A '--------' A '--------' | : | | | : | | .--------. | : | | | | | : | '-----| |----o : | | | | : | '--------' | : | | : '----------------------------------------' : (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de) : : then the "minor loop" compensation isn't much but a fancy way of adding : feed-forward.
A minor loop is not the same as feed forward. Feed forwards are open loop gains that are proportional to the reference and its derivatives and summed with the output of closed loop sections to form the control output. I don't see how an inner loop can be mistaken for a feed forward.
There is another form of feed forward where the reference is run through a filter so there is an exaggerated pseudo reference. This is similar to leading the donkey with a carrot by slightly exaggerating the path.
The rest of your desciption is good.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Peter Nachtwey wrote:

My thinking was fuzzy, and you're part way correct.
In this case the minor loop doesn't make any substantive change in the loop behavior over what you could get with a controller that combines feed back and feed forward -- but only if H2 doesn't have any slow or unstable poles.
Here's why: given my additions to the above diagram, you'll end up with a transfer function that reads
G H1 T1 = -------------- 1 + G(H1 + H2)
On the other hand, if you have a block diagram that looks like:
.------. | | .---------->| Hd |-----. | | | | | '------' | | | | | + | _ .------. V .-----. | + / \ | | + / \ | | ---o-->| + |-->| Hb |-->| + |-->| G |----o-----> \_/ | | \_/ | | | A '------' '-----' | -| | | | '-----------------------------------' (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
Then you'll get a transfer function like this one
G(Hb + Hd) T2 = ---------- . 1 + G Hb
But if you set Hd = -H2, and Hb = H1 + H2 the two transfer functions are equal. So mathematically they're the same. Practically there will be some pole-zero cancellation, but as long as any poles in H2 decay quickly they won't show up as weird uncontrollable poles in the actual application.
Where the fuzzy thinking _really_ came in, however, is that both of the above methods can be realized as a general 2-in, 1-out state space controller -- and that's usually how I deal with them. So I just stamped them as "equivalent" without thinking my discussion through.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I don't think BO's system lookedlike that.

It definitely doesn't look like that. You show a feed forward. There were no feed forwards in Bo's transfer function.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

Correct.
My system is G1->G2->G3 with H feedbackbetween G2 out and G2 in, and unity feedback G3 out to G1 in. My readers is so hosed with fonts, I couldn't make much sense out of Tim's blk diagrams...
Thanks,
Bo
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Hopefully you have turned in your home work by now. Below is a link to my interpretation of your home work. ftp://ftp.deltacompsys.com/public/NG/Homework-BO.pdf Did I interpret your system correctly? I verified what you claimed about the velocity constant of the original system being 1000 so I figured I couldn't be too far off. It is hard to make sense out of block diagrams written with a text editor. I am not an artist so I didn't take the time to draw a block diagram of my interpretation of your problem but you should be able to tell from the transfer function. Page 5 is where I modified the minor loop to change the velocity constant.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

Yes.. You have it. I should get my HW back this evening...so we'll see.
I think you have Ti right on page 5--but your overall transfer function (I think) shows the series compensator and the minor loop compensator in the system--instead of just the minor. Take out the series compensation and I'm pretty sure the kv will then no longer be 1000.
Nice document-- what did you use to create it? Matlab?
Thanks for taking so much time--that was way more effort than I was asking for--and I sincerely appreciate it.
Best regards,
Bo
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.