Re: Re: E.M.C. PID Tuning - HELP !!!!

Jeff. I mixed your comments up a bit and mine into them.

>    From: "ja_erickson" <ja_erickson@...>
> Subject: Re: E.M.C. PID Tuning - HELP !!!!

> this machine has the original steppers from bridgeport

<s>

> if it matters i am
> using a microstep "gecko" drive for this retrofit project.

Yes! It does matter a lot because if this is the Gecko 201 or 210 set up
for size 42 motors you have a good motor/drive combination. We don't have
to worry about resonance or missed steps from the hardware so long as you
keep acceleration and max velocity to a reasonable value.

Since your tuning affects performance I assume (ass of me!) that you are
using freqmod rather than steppermod. Freqmod should produce a fairly
smooth pulse train but it may limit your top end so I'll talk about that
first. This depends upon the speed of your PC, the PERIOD, INPUT_SCALE and
OUTPUT_SCALE (pulses per unit), and MAX VELOCITY. You will know when you
get there because to small a PERIOD will cause major delays in things like
mouse pointer movements and position updates. When values of the other
variables get to large they cause RT-Linux to fail and reboot or go dark.
(the black screen of death).

Let me add a note here about RT-Linux crashes. (I said RT-Linux not
Linux.) These crashes along with those from power failures can cause file
system corruption. I cause them often during my experimentation. I've
tried all of the recommended procedures to recover from these crashes and I
think the most reliable way is to simply press reset. If you are using the
standard file system, e2fsck takes over on reboot and attempts to fix the
files up. It may not be able to and will cause some parts of the software
haystack to become flaky. You'll see it show up somewhere during a run.
Something unexpected will begin to happen. It is not likely to cause any
problem with the EMC but perhaps an icon won't work like expected or you
may drop out of X-windows. Keep backup copies of your run and ini files
and when you begin to experience the unexpected, reinstall.

> i just returned from
> the garage with a real good feeling as i have had a good tuning
> session. i have arrived at a setting of 100 for the 'p' variable and
> a 5 for the 'i' variable. by adjusting these two variables in unison
> i was able to use a lower 'p' value which seemed to smooth the
> physical stepping characteristics of my motors at slower feedrates
> while allowing them to attain greater rapid traverse velocities. in
> comparison i needed a higher 'p' value to achieve the same rapid
> feedrates without the 'i' value.

Good stuff. Sounds like you're getting the hang of "playing at" tuning.
What you might do is reduce the (I) value and add in some (FF1). Remember
to change one value at a time and keep a record with a simple better/worse
evaluation.

> i determined that my machine has a
> backlash of .0015" and added that to the .ini file but the machine
> began to wander before and after its commanded moves which i think is
> a really strange situation. in order to rectify this problem i began
> to experiment with the 'deadtime' variable and found that by using a
> very small value '.0004' it made the wandering go away but at '.0003'
> the wandering only happened once in a half hours worth of testing.

Let me talk about backlash comp and deadband in separate paragraphs and
then attempt to explain what I think is going on. Since you seem to be
using 2000 pulses per unit, each step is half a tenth. (I know, I assumed
inches) Since the EMC uses much finer positioning than that, there are a
lot of commanded positions that your steppers can't drive your axis to.
For example you might be able to reach 1.0005 and 1.0010 but not 1.0007.
So when the last value is commanded, your motors will hunt between the
first two. With steppers, or coarse encoders you will need deadband that
is more than half the distance between steps or pulses. This allows the
control to say, "close enough" and stop trying to reach the exact actual
position that has been commanded. Fortunately the EMC remembers where it
really should be so that deadband slop is not cumulative.

Backlash comp is a different can of worms. There have been some confusing
reports about the EMC's backlash comp and I don't recommend using much of
it. In fact, Joel Jacobs demonstrated (at NAMES last year) that if you add
in backlash comp and then successively home your machine, you will get the
kind of cumulative errors that you describe. Beyond this problem, backlash
comp is of real concern to even the biggie commercial CNC builders because
it can often be fooled by cutting forces, deceleration, and other
paranormal forces. <g> A Mazak service tech told me the other day, "Don't
expect it to always take up the amount that you put in."

The 0.0015 backlash comp with your machine would be 3 pulses added in when
an axis reverses direction. I seem to remember a comment in the code that
says something about feeding in backlash on successive motion loops rather
than all at once. I've got this crazy impression of something like halving
the difference on each loop which led me to the conclusion that an even
number of pulses for backlash comp might be better than odd numbered.

Now for my SWAG/WAG about this "wander." I don't quite understand the term
and could get closer if you are a bit more specific. I'll guess that it
stops and then takes a few steps one way or the other at very slow
feedrate. I'm thinking that it has to do with the integral (I) value that
you've put in. The integral component builds up when there is a change in
velocity. Integral really likes steady state. When integral begins to
build up the motion planner has to somehow feed its offset back into actual
position. It does this with math based on the other values -- in this case
(P). It causes a bit of overshoot and rounding (persistence) when velocity
drops suddenly and a bit of undershoot when an axis accelerates. Kinda
like an S curve rather than sharp angles. "Course I could be all wet here,
the snow is beginning to melt.

> i wrote a small g-code program and had a dial indicator set up on the
> test axis and began to see if the machine was missing or adding steps
> as it processed the file.to my surprise there was a cumulative error
> happening as the program ran i ended up having to increase the input
> and output steps to a weird value of 2008 instead of the calculated
> 2000, but this machine now runs and repeats flawlessly. i have read
> somewhere that if the motor driver that your using expects to step at
> 1 and the software starts a step at 0 then this anomaly may happen
> but i dont know how e.m.c. operates. could you give any explanations
> or suggestions on what might really be going on with this value of
> 2008?

Good on you again! Testing a retrofit is the key to getting it set up
properly. Repeating a test over and over gives you confidence in your
work. Does this happen both with and without backlash comp? Does it
repeat at different places on each axis? If yes, then setting the 2008
value is the correct solution. There is nothing sacred about even
multiples of a thousand here -- even if the math from all of the
manufacturers of the components that you are using say it should be. OTOH
if the screws run out of true you can set up some compensation files.

HTH

RayH -- U.P. Michigan