Re: [CAD_CAM_EDM_DRO] 3D Contouring - Loss of Accuracy

Peter wrote:

>Hi all,
>
>I'm stumped! On my BP-clone knee mill, I've tried everything I can
>think of and nothing seems to produce the results I'm looking for. What
>I find is that running a large 3D file I gradually accumulate a small
>error typically in one of the most active axes which often exceeds 0.3mm
>or .012" after half an hour to an hour of running time. It is usually
>in the same direction, but not always. Below are some of the things
>I've tried:
>
>Large Steppers couple directly via heli-cal couplings running G210
>Geckos and Flaschcut CNC - 650VA PSU
>Large Steppers couple directly via heli-cal couplings running G210
>Geckos and Indexer LPT & G-Code Controller - 650VA PSU
>Large Servos running G320 Geckos via 5mm HTD belts & reduction pulleys -
>both Flashcut and G-Code Controller - 1500VA PSU.
>Large Servos running Rutex R990's via 5mm HTD belts & reduction pulleys
>- both Flashcut and G-Code Controller - 1500VA PSU
>
>Even if I remove the couplings or belts (so the motors aren't loaded)
>the error remains.
>

I assume you determined this with a mark on the motor, and after running
a program through
you returned to the starting coordinate, and found the mark did not line
up. It is possible there
is a resonance problem, but there is something else you need to know
about Gecko drives.

Unlike almost any other drive, the Geckos require that the direction
signal never change except
right BEFORE a step pulse. All other drives I've seen want the
direction to be held for some
interval AFTER a step pulse, then the computer is free to change the
direction line.

If a program was not set up to do this, it could easily cause lost
steps. What happens is that
steps come out of the Gecko, especially step multiplier/microstepping
Gecko drives at some
time after the step command is given. Depending on the rate perceived
by the phase locked
loop, the steps will be sent to the motor until there are no more to
send. If the direction
input is changed during the time that the drive still has steps to
output, they will be generated
in the WRONG direction. (Mariss, correct me if I'm wrong here, but that
is how I interpret
the specs of the G210 and G320.) These steps SHOULD come out in the
same direction as
the controller saw when the step pulses ocurred, but the drive will
change direction whenever
the direction signal changes.

At very slow rates, the direction line is unlikely to change while steps
are still being handled
by the drive. As speeds and especially acceleration is increased, the
possibility of the above
problem becomes more serious.

I have provided a switch on my stepper controller board called the
"Mariss" switch, after the
maker of the Gecko drives. It adds a flip-flop to allow the direction
line to only change
at the leading edge of a step pulse. You could add this externally
between the parallel
port and the drives.

One other possibility is that the wiring you have set up has the
polarity of the step pulses
wrong. This could allow the last step before or the first step right
after a direction
reversal to move the wrong way, somewhat similar to what I've described
above.
The drive instructions should make it clear what the polarity of step
pulses should be,
in relation to the direction signal.

If this scenario is correct, you should be able to cause the error by
making repeated
reversals of one axis only. One possible program might look like :
N10 G01 F40 X1.0
N20 X0.1
N30 F1 X0
(repeat from block 10)

This will make a slow approach to X0, then a rapid feed to X1.0, and may
be more likely
for the error to accumulate in one direction. The program should be run
with the non-zero
coordinates made negative, in case the direction timing is sensitive to
timing of the
rising or falling edge of direction. You might also just do a repeated
move of +/- .1" or so,
because if I'm on the right track, it is the REVERSALS that are causing
the problem.

> All servo encoders are running in differential mode.
>
>I've tried both old and new versions of Flashcut and the current version
>of G-Code Controller. These tests have been run over the last (almost a
>year) and in each case, a similar magnitude error occurs. I know one
>would then start to suspect my CAM program - Visual Mill but I run in
>absolute mode and I can see the positions at the end of the test file
>specifiying either machine zero or program zero and then using my limit
>switches or long nails hotmelt glued to the pulley as a zero reference
>when the controller zero's the table, the error is there...
>
>If I run relatively simple 2D or 2.5D files the error doesn't seem to
>occur - it is only a function of large multi-axis contouring files.
> Some of these problem files have 10,000+ lines of g-code code -
>typically creating a "point cloud" that the software then contours.
> BTW, I'm not criticizing the abovementioned products - they work great
>in everything except these large 3D files. I seeking suggestions for
>what nugget of wisdom I'm still missing.
>
>

If you truly can't get a failure when moving only one axis at a time, it
STRONGLY points to
software! I suppose it is possible that current fluctuations from one
drive are affecting other
drives in some manner. Proper grounding between the Gecko drives, and
location of low ESR
capacitors right at the power inputs may help. If it was only happening
on full-step stepper systems,
I would say this is almost certain, but the Gecko servo drives should be
very immune to this.
I'd love to run EMC on your system and see if the problem is still there.

Hmm, what OS are you using, do you have EMM386 running? That seems to
corrupt timing
on a number of step-based systems.

>Is it possible that even a servo system can occasionally lose a step or
>two per million?
>

Not likely, if it is done right. You mention differential encoders,
which should help enormously.
Are the encoders only grounded at the Gecko drives? If the encoders are
also grounded to the
machine, that could contaminate the signals enough to even nullify the
differential inputs.

> If so, could that be why commercial CNC machines use
>glass scales mounted on each axis to provide an absolute position
>feedback loop in addition to a (motor) shaft mounted encoder?
>

No. This is for correction of machine-based errors such as leadscrew
error and expansion.
The end up using the shaft encoder as a tach, mostly. If it gets errors
in the shaft encoder, why
wouldn't it get errors in the linear encoder, too?

> I'm not
>quite sure how to incorporate such a thing, but I think it may be
>possible with G-Code Controller and Indexer.
>

Sensor fusion with two high-accuracy encoders that give conflicting
readings sounds like a
nightmare.

Jon