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

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>

>>
>> Not sure what you're looking for here. I think Alan wants to know how
>> to do interpolated moves of multiple axes? Wally wants a "driver???"
>> for EMC?
>
<snip>

>>
>> Since Mariss provided the circuit, keep in mind his "pulse
>> multiplied" drives may allow some of these high freq. apps to work. I
>> haven't "done the math" to see just what sort of errors accumulate at
>> different angles of 2 or 3 axis motion. (doing it the way Alan
>> suggested; set it and go!)
>
>I'd still like to know if this is the intent (set rates and go),
>otherwise, as in a software implementation, each pulse is generated
>individually by DDA code.
>
>>
>> As for "EMC driver", what do you mean? Do you want to incorporate
>> this pulsegen circuit into EMC? If so, Mariss has provided the info
>> needed to get started in the .doc file. (send 2 byte "rates" 1024
>> times/sec for each axis, I believe)

<snip>

>>
>> The "grandfather" of the linear interpolation algorithm used by many
>> graphics applications is Jack Bresenham, who used to work for IBM and
>> in 1965 wrote a paper for IBM's system journal titled(i think) "a
>> fast line drawing algorithm". He's now teaching at a university in
>> the eastern U.S.. A nice man to talk with, but do some research first!

<snip>

>
>> Another fast circular interp is in the book "numerical methods". I'm
>> working from memory so I don't have the authors name. Source in C in
>> the book and included CD.
>
<snip>