Re: Re: step pulse timing resolution

Jon Elson Wrote:

>Well, using a timer, it is easy to do arbitrary granularity for ONE
>axis, but it gets into big trouble with 2 or more! What if you have
>two axes that need pulses that will come out very close together?
>Of course, you can have some code that figures out when this is
>going to happen, fudges the pulses at the same
>time, and then compensates later. The more axes, the more fudging
>will go on.

Jon,

You are exactly right.

Unless you are running co-ordinated and independant timing for each
axis you WILL have these sorts of issues. And if perfection of motion
is the goal, you will be limited TO such a setup.

Everything we do here is about defining, determining and controlling
the error(s).

Its always:
1.Where are we? (current position)
2.Where SHOULD we be? (commanded position)
3.Are we close enough to where we SHOULD be? (error)
4.If not,What do we NEED to do to get there? (correction)

With one timer, we must "slave" the axes to some "master".
Traditionally this "master" is the axis making the longest move. All
other axes are run at some sub-multiple of this.

As long as these sub-axes(distance) are factors of the "master", time
and position correspond and there is no problem. For example:

With x=12,y=4,z=3 (numbers are in steps/units to move) we can set any
arbitrary "rate" of pulse output, and the position at any point is
exactly where it should be.

But if x=12,y=5,z=7, we've got problems! This is where traditional
stepper systems and servo systems diverge.

As a blanket statement(please don't beat me up re: this) Stepper
systems control position directly; servo systems control position as
a function of time.

So the stepper system says, How the heck am I gonna get 5 and 7 steps
divided evenly into 12??? and it does the best it can, which means
the position is NOT going to be where it SHOULD BE.

The servo system says, No problem, I'll speed up(increase current) to
the sub-motors such that we all arrive together. The analog component
of the servo system comes in and saves the day. BUT, the servo GETS
its position information from a DIGITAL encoder(typically). Leading
to the same sort of problem, but on "the other side, so to speak" of
the problem.

So how is all this resolved?
By accepting that we're not always gonna be where we think we are(#1
above) and; we may not BE ABLE to do anything about it(#4 above).
So we modify our assumptions re: error(#3).

The net point of all this is to say that "good enough" is a LONG way
from mathematical perfection. And that's OK. If our parts meet our
needs.

Ballendo