interpolation and algorithms of multiple axes was Re: Pulse Gen

Hi,

Jeff, I could not agree with you more. The "pulse multiplied" step
drive is indeed a bandage for a system that cannot generate pulses
fast enough.

Why can't it? Because the computer is being misused by having it
execute mindless timing loops for freq. generation. This is best done
with very simple external hardware. That way you could have megahertz
step rates AND a fancy Windows GUI.

The output would indeed be a velocity command, but the ext. hardware
would also generate an interrupt from the same xtal oscillator that
runs the pulse gen. Position would then be the digital integral of
the velocity; i.e. simply add/subtract the velocity to/from the
position register every interrupt.

I have used this pulse gen circuit with a Z80 CPU this way and it
worked perfectly.

Mariss

--- In CAD_CAM_EDM_DRO@egroups.com, Jeff Barlow <jeff@b...> wrote:
> Hi folks,
>
> I'm a bit short on time of late so I'm sort of skimming through this
> stuff. I do want to jump in here with a few odd bits of "thinking
out
> loud", though.
>
> I don't have it here with me but I'm pretty sure one of Knuth's
books
> covers this stuff. Is that the "numerical methods" book being
referred
> to, perhaps?
>
> The Bresenham algorithm is the classic one, all right. Someone
referred
> to the fact that this is how diagonal lines get drawn on your
computer
> screen. I would like to point out that on any halfway modern system
this
> is not being done in software but in the hardware on the video
card. If
> I'm getting the jist of this correctly, the so called "pulse
generating
> black box" that we're talking about is simply another (much slower)
> hardware implementation of this algorithm.
>
> I'm starting to recognize a familiar pattern here: people tend to
use
> the tools they are most comfortable with. Presented with the same
> problem, programmers start writing code, hardware designers start
> designing hardware. As luck would have it, I've found myself right
in
> the middle of this sort of muddle many times.
>
> What I think I've learned is that if you don't take the time to get
the
> system partitioning right before you start writing code and
designing
> hardware you end up working way too hard to make something that only
> sort of works. I would say that the stepper code in EMC is a prime
> example of getting this wrong. Mariss's "pulse multiplied" drives
are
> typical of the sort of "bandaid" fix that this sort of poor system
> partitioning leads to.
>
> It seems clear to me that a better partitioning choice is to have
the
> software calculate the pulse rates while the generation of the step
> pulses themselves is best done in hardware. Since a standard PC
does not
> include any appropriate hardware we need the "pulse generating black
> box" that Jon Elson and Mariss, it appears, are both now working on.
>
> It is useful to note that the above mentioned pulse rates are in
fact
> velocity commands. This leads me to the realization that the
seemingly
> "correct" system partitioning is where the hw/sw interface consists
of a
> velocity command and position feedback, much like the current EMC
servo
> code.
>
> I hope this helps to get us on the same page.
>
> Jeff