RE: freqmod.o in EMC started, now questions

Hello Jon,

Thanks for the explanation of P and FF1.

I am not sure how the code is working, but no I am not using the encoders
with the steppers. I am guessing that EMC is tracking the actual position as
an assumed value bases upon the movement per step calculated from the .ini
parameters x the number of steps commanded. The problem then is the
commanded position is never actually reached as one step is just shy of the
position and the next step is just past.

Wish I could hook the encoders in and get a real closed loop system. I did
notice as I was compiling the file Matt had me change that there is a
reference to a DRO file. I didn't look, but I wonder if that is the
beginning of using one of the Kulaga/Mauch DRO cards for stepper feedback?


Tim
[Denver, CO]

> -----Original Message-----
> From: Jon Elson [mailto:jmelson@...]
> Sent: Sunday, January 30, 2000 12:11 AM
> To: CAD_CAM_EDM_DRO@onelist.com
> Subject: Re: [CAD_CAM_EDM_DRO] freqmod.o in EMC started, now questions
>
>
> From: Jon Elson <jmelson@...>
>
>
>
> Tim Goldstein wrote:
>
> > From: "Tim Goldstein" <timg@...>
> >
> > OK, with the EMC Board of Knowledge online I have gotten EMC to
> come up with
> > the new freqmod.o module for steppers and it does run the machine with
> > faster movements.
> >
> > Now for the questions:
> > What does the P and the FF1 parameter you play with really do?
>
> P is the proportional gain. So, error is multiplied by P to give the
> output velocity request. FF1 is applied before the trajectory velocity
> goes into the above calculation, and it adds a term for rate of change
> of the required velocity. It helps sluggish drives by
> effectively increasing
> gain when the trajectory has a change in velocity.
>
> > Why do my steppers sit and buzz after a move? I actually think
> I know this
> > answer which I think is the steppers are hunting back and fourth about
> > .0002" trying to get where the feedback position matches the expected
> > position, but the steps are not fine enough to get a zero
> difference. I do
> > see the actual positions oscillating a few ten thousands. So, the real
> > question is not why, but how do I get them to just sit still
> when at rest?
>
> I gather you are using encoders with stepper motors?
> If so, you need to reduce P. This is actually a crude method, and not
> really desirable. A better way is to hack the code to allow a deadband.
> You figure out what this range of hunting is, in terms of linear units,
> and if the absolute value of the position error is less than this
> figure, you
> set error equal to zero. Assuming this is a small range of a few
> ten-thousandths,
> it should have almost no effect on accuracy or smoothness.
>
> Jon
>