The bottom lie with controllers is that we trade simplicity for performance
and at some point just have to say "good enough".

You really do have to know what you are measuring and what you are
outputting.   It is this I think you are measuring position (not velocity)
 So the "error" is distance or degrees.  What or outputting is a PWM value
which in the end works out to "acceleration."   So this PID controller is
controlling position by adjusting acceleration (force).      What is "D"?
  It is the rate of change in what is being measured or the rate of change
of position, we call that "velocity" in English.   And what is "I"?  That
would be like a car's odometer reading, total distance traveled.

Note that this PID controller is very different from one that controls
spindle speed.     In that case we measure velocity and control
acceleration and "D" is the rate of change of velocity.  We call this
"acceleration"  And what is "I"?  That would be velocity integrated over
time, we call that "position".     So both "I" and "D" are very
different here then in the above PID.

Back to the case of using PID to control to position of a massive axis that
has low friction....
Using only "P" is like drivng a fully loaded semi truck using only the gas
pedal.  When you get to the parking spot and take you foot off the gas the
truck just keeps moving unless you have brakes.  With just "P" there are no
brakes.  You need something negative to oppose forward motion are you never
stop .

PID is not the best kind of controller for this.  PID is purely reactive
and never plans ahead and will never give optimal performance in the case
where you use acceleration to control position.    The smarter truck driver
knows how effective his brakes are at different speeds and loaded gross
weights and can see the distance to the parking space.  He fully calculates
a good-enough trajectory plan and then only makes tiny adjustments to his
plan as he drives and if he is good the truck stops right on the mark.   We
can do this with computerized motion control but "MPC" controllers are
needed which are perhaps 200X more complex than PID controllers.  So we
stick with PID and learn to accept the performance hit.

While getting a perfect plan using MPC is hard, sometimes getting a good
plan is good enough and people sometimes use a nested PID for this.   The
first one controls motor velocity and works well because velocity is so
much easier to control.   Then a second PID controller is used to provide
velocity set points to control position.   The nested PID is only 2X more
complex than a single PID, not 200X like MPC.

My understanding is that LCNC does use nested controllers and does have
some form of look-ahead planning.  I know that I don't know how to use that.


On Tue, Dec 8, 2020 at 8:56 PM Gene Heskett <ghesk...@shentel.net> wrote:

> On Tuesday 08 December 2020 19:56:13 Chris Albertson wrote:
>
> > If the output of the PID controller is force ad the measured feedback
> > is the position, a P only controller will always oscillate.  Friction
> > will damp it eventually.   A negative "D" will reduce the velocity and
> > help with overshoot and "I" is required if the final result has an
> > offset.
> >
> > The root cause is the force is a couple of steps removed from
> > the position.
> >
> > If you want the system to go full speed then slam on the brakes at the
> > last minute and hit the marks then you need a controller that has a
> > physical model of the system and use that to predict the future and
> > plan ahead.  PID is always reactive.  It can't look ahead.
> >
> > But PIS can come close.   After you get P tuned "close" try "D" and
> > depending on how it is wired may be negative
> >
> I'll give that a try tomorrow. Or maybe right now since I wasn't sleeping
> well.  And with a Dgain of -2.5 got a 22mv error at 101 degrees a minute
> with little, maybe 10% ringing on the rising edge, and a less than 10%
> peak "effort" in reverse to stop it, That is a major improvement and
> doesn't trip off the psu getting stopped.  What does that 22mv mean in
> folllowing error since I have that set for about half an inch at the
> moment?
>
> This I think might be good enough to go ahead and finish the mount
> machining and get it installed on the bs-1.  With all the excitement and
> sadness here, I've only been working on easily interruptible things.
>
> Thanks Chris.
>
> > On Tue, Dec 8, 2020 at 4:42 PM Gene Heskett <ghesk...@shentel.net>
> wrote:
> > > On Tuesday 08 December 2020 19:05:52 Chris Albertson wrote:
> > > > What next?  You have set P-gain but what about I and D gains?
> > >
> > > That has been tried, gently, but doesn't seem to have the desired
> > > effect.
> > >
> > > > On Tue, Dec 8, 2020 at 12:49 PM Gene Heskett
> > > > <ghesk...@shentel.net>
> > >
> > > wrote:
> > > > > Lo all;
> > > > >
> > > > > I'm back to playing with the servo again, following John
> > > > > Thorntons instructs from the wiki article.  And I note a couple
> > > > > things.
> > > > >
> > > > > 1. The pid_a.FF1 value has little or no effect on the amplitude
> > > > > of the error. So that probably needs addressed by educating me
> > > > > on how its calculated.
> > > > >
> > > > > 2.pid_a.FF2 isn't working as that article says it should, a
> > > > > little effect on the shape but zero effect that would lead to a
> > > > > zero error when cruising
> > > > >
> > > > > 3. pid_a.Pgain effects the amplitude of the error signal, with
> > > > > about 350000 being the onset of a low level oscillation, about
> > > > > 10% when cruising.  But its also the lowest error at 15 to 20
> > > > > millivolts.
> > > > >
> > > > > 4. I am getting some improvement. but nothing like the pix on
> > > > > that wiki article.
> > > > >
> > > > > It explains that pid_a.FF1 should be 10/velocity@10V (velocity
> > > > > is in machine units per second).  Since I do not yet have the
> > > > > motor actually moving the BS-1 clone, nor have I managed to get
> > > > > a home switch set up so I can actually measure the scale, the
> > > > > scale temporarily set is likely wrong. Since I've 2 worms in
> > > > > series, for playing I've a high value set for scale, 5000. With
> > > > > the encoder on the back of the motor it could well be higher
> > > > > than that.
> > > > >
> > > > > But no combination of numbers results in a cruising error of
> > > > > zero, its alway plus at cruise speed.
> > > > >
> > > > > And if I go at more than about 30% high pwm, motor inertia
> > > > > causes the servo to use reverse to stop if I ask for more than
> > > > > 60 degrees a second. This use of reverse causes the supply, a
> > > > > 350 watt 24 volt switcher, to do a shutdown because it thinks is
> > > > > been crowbarred, and the powerdown to recover is around 3
> > > > > minutes.
> > > > >
> > > > > I think I might have a way that will fix that as this driver can
> > > > > do crowbar the motor braking if the signals are re-arranged and
> > > > > fast enough. If I setup a hardware timer in the form of a a
> > > > > retriggerable ooneshot drive  from the pwm signal, which is
> > > > > running at 4 kilohertz, or 250u-secs pulse is a 100% signal, but
> > > > > the timer timesout in 200 microseconds, it will time out and
> > > > > apply the brakes for whats left of the 250 microsecond pwm cycle
> > > > > if the pwn drops below 20%. This should slow the motor fast
> > > > > enough it will never actually use reverse to stop.  And that
> > > > > mode will never effect the psu.
> > > > >
> > > > > But first, what can I do about the ineffectiveness of setting
> > > > > FF1 anyplace between .5 and 25. I think its effecting the motors
> > > > > cruising speed but has zero effect on the amplitude or shape of
> > > > > the error if enough Pgain is used to make it follow well.
> > > > >
> > > > > With Pgain at 250000 it cruises stably, with a reasonably flat
> > > > > top to the error, about 20 millivolts of error, but FF2 seems to
> > > > > have little effect on the initial overshoot, or the overshoot
> > > > > when stopping, and its the overshoot when stopping that is
> > > > > shutting down the supply unless I set max jog to below 60 so
> > > > > friction stops it. That 60 is about 1/3rd of what the motor can
> > > > > do in terms of output shaft rpms if fed its normal 24 volts.
> > > > >
> > > > > Anybody know what I should look at next?
> > > > >
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to