Re: Skipping steps, avoiding resonance

Hi,

There are two issues in play here; circuit related and software
related.

Circuit related:

This has to do voltage, current and timing of the step signal. The
step pulse has to meet 3 criteria to be valid and the drive to
operate properly. This is generic to all drives, not just ours.

1) Voltage of the step pulse. Most drives use opto-isolators for step
and direction. The LEDs are current operated, so the pulse source
must have enough "muscle" to provide it. If it does not, then the
step pulse voltage sags, the LED isn't fully on and the step is
missed because the drive simply didn't "see" it.

Most digital outputs (including the parallel port) do a much better
job of sinking current than sourcing it. While it may easily "short"
30mA from a +5V connected load, it would be hard pressed to output
10mA into a load connected to ground.

2) Step pulse width. All drives have a minimum step pulse width
specification. This means if a pulse width (0V to 5V, then back to 0V
time) is less than specified, the drive again won't "see" it.

3) Step pulse rise and fall time. A step occurs on a particular logic
edge. Let's say the step pulses look like: ..055005500550.. The step
would be "clocked in" say on the 5V to 0V edge. If the voltage falls
from 5V to 0V slowly (5554321000), any noise riding on the step pulse
would be "seen" as additional steps. That is why the step input must
not be driven from an external opto-isolator. They are very slow (>
1uS).

If (1), (2), and (3) are satisfied then every intended step will be
taken and no unintentional (noise) ones will be. Usually (1) is the
most common troublemaker with (3) coming in as a distant 2nd.


Software related:

This has to do with step pulse timing and the placement of the
direction change relative to the step pulse.

1) Step pulse timing. A step motor drive is a very stupid but
faithfull device. If you send 10,000 full steps per second without
any acceleration, the drive will faithfully pass every single one to
the motor. The motor, being a little brighter, will refuse to follow
them.

The same thing happens if the step pulses are "ragged", meaning the
timing between pulses changes abruptly. What may run very smoothly
when the software is doing something easy may run rough because the
software becomes busy and cannot put out evenly spaced step pulses.

Ragged step pulses impose continuous accel and decel demands on the
motor which it may not be able to meet. Meanwhile the drive does
exactly what it is being told to do.

2) Direction change. As said above, a step is "clocked in" on the 5V
to 0V edge of the step pulse. What if the direction is changed on the
same edge? Which way should the step be taken, CW? CCW?

That is the reason why the software should have the ability to invert
the step pulse output. Then the direction change is made on the
alternate, inactive edges (0V to 5V ones).

Mariss

--- In CAD_CAM_EDM_DRO@yahoogroups.com, Chris L <datac@l...> wrote:
>
>
> Peter wrote:
>
> >Hi Randy,
> >
> >I've had a number of similar problems with 3D contouring and lost
steps
> >on a BP clone retrofit. In spite of a LOT of experimenting, I
never was
> >able to resolve the mystery with my stepper motor setup but I have
made
> >significant progress since converting the mill to servo motors. I
still
> >don't understand why a stepper system wouldn't work - provided the
> >motors have sufficient reserve power etc., it should have worked!
I was
> >running direct drive 1800 oz-in steppers with Geckos and Flashcut
> >software. I should point out it worked great for all my 2D and
2.5D
> >stuff.
> >
> (snip)
>
> Peter,
> Your not alone with your peculiar loss under 3d compared to 2.5d
with
> the Geckos under FC control. I know of 2 others with the same
issue. I
> wish they were nearby so I could go and fiddle with them. It must
come
> down to compatabilities. It's not necessarilly a Gecko problem, nor
is
> it a FlashCut problem. Both sides have stable use reported.
> Compatability problems can give you grey hair fast. That is why I
> always recommend a "whole system from the same Vendor" when I sell
a
> plan set. Obviously, most of us can not afford to do that.
>
> FlashCut has taken some steps to add more configuration in regards
step
> and dir output. It looks like the newer versions will include
additional
> configuration settings for ""lead" or "trailing" timing , so you
have a
> better chance of making things work no matter what driver. The
> compatability issue is not unique, I have used other controls that
> needed signals "cleaned", "inverted", "delayed" Etc. Not that I
always
> did it, but I knew it needed it done to work right. Flashcut has
> typically worked with the bigger name drivers that we hobbiests
can't
> always afford like Anahiem and IMS.
>
> I'm finding it works great with the API's tim Sold... Again,
pricey
> drives. I'd be curious for someone like Mariss to tell us why there
are
> these differences in drivers.
> After a while, we can get in a corner trying to explain why we need
to
> spend more time with a machine than our wife just because we
lose .001"
> occasionally!
>
> With the older version of FC, I have found that sometimes you can
use
> all the wrong Signal settings to make it run right with some
drivers.
> (you'd need to be a rocket scientist to figure out why} It can have
an
> affect on speed, but at least it ran.
>
> In that you moved on to servos and still suspect issues, it might
be
> possible that you could benefit from the new versions additional
> settings when it gets released.
>
> Chris L