Re: [CAD_CAM_EDM_DRO] interpolation and algorithms of multiple axes was Re: Pulse Gen

Hi Jeff,

Thanks for "drooping in"! David (?) Knuth was the author I was trying
to think of. If I still have it (problem with "open libraries". So if
we need to implement a DDA for linear and circular interpolations, we
ought to do all that in hardware! Yeah, that's the ticket!

It's still not clear to me if just generating a rate for each of the
axis involved in the move and waiting for the endpoint is OK. And, what
do you do for circular interp? Those rates are constantly changing, if
I understand it correctly. OK, then we constantly change the rates. It
will take me a while to ketch on! ;>)

It is said that ANY software algorithm can be implemented in hardware.
So it is conceivable that we can implement Bresenham's algorithm in
hardware that some of us hobbyists can build too! That would certainly
be a GREAT BOX!

Alan KM6VV


Jeff Barlow 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
>
> On Wed, 06 Dec 2000 12:44:31 -0800, someone or other wrote:
>
> <snip>
>
> > Goes back to the Generic "black box" that
> >several of us think we should be using for generating pulses.
> >
> <snip>