Re: A Z80 guy needs help!

Chris,

Actually rounding errors become second-order effects. The output
velocity is simply the difference between the last position and the
current one (1,024 x,y coordinate pairs per second). Rounding errors
manifest themselves as "jitter" between two adjacent velocity
increments. Since 2**16 evenly spaced velocities are available, this
quantisizing effect is negligable.

Regards to the circular interpolation path; this method generates
1,024 arc segments/sec regardless of radius or velocity. A 10" radius
circle traced at 1"/sec would yeild a 64,340-sided polygon (2pi * 10
* 1,024). Each arc segment would be 0.00097" (1/1,024) long.

Sine and cosine is not that expensive if done very carefully. I can
generate a sin-cos pair accurate to 24 bits in about 1,200 clock
cycles on a processor that has 16 bit hardware multiply. That would
take about 60uS at a 20MHz clock rate, or about 6% of a 1,024Hz
period.

It is much simpler for linear interpolation. Since a vector line
segment has a constant angle, sin and cos are calculated only once
and constant for the duration of the segment. There:

Vx = (D + delta) * sin(theta) - D * sin(theta)
Vy = (D + delta) * cos(theta) - D * cos(theta)

Again, replace D with D + delta for the next time increment.

Accel and decel is easily handled using only add and subtract. The
distance taken to accelerate to the programmed vector velocity or to
the half-way point along the vector is kept track of by simply
summing the velocities while accelerating. When the "distance to go"
is equal to this value, then deceleration is effected and becomes the
mirror image of acceleration.

What is cool is that the rate of acceleration does not have to be
constant (a linear ramp). Rather, the current velocity value can be a
pointer into a data table that can hold any arbitrary acceleration
profile (parabolic, exponential, you name it) at little additional
computational expense.

All of the previous is interrupt driven at a 1,024Hz rate, and I call
it the "velocity manager module". The background program handles
serial communication, code parsing, calculating vector segment
variables needed by the "module" and keeping its "variables" buffer
full.

Since all motion is vector based, arc and linear segments can be
concancated in any combination. The decision then is whether to honor
the concancated vector path or the programmed vector velocity. The
former has been worked out, the latter will soon fall in place.

My intention is to make the software as well as the hardware "open"
so that others who are much better software programmers than I can
improve or modify it as they please.

If you or anyone else wishes to pursue this in greater detail as the
project progresses, please contact me off-list.

Mariss

--- In CAD_CAM_EDM_DRO@y..., ccs@m... wrote:
> That is an interesting approach. I think you would have to be very
> carefull to prevent accumulation of roundoff error - ie, you will
have
> to round the velocity to whatever precision you can express it in,
and
> then recalculate the move time so that the move total comes out
> exactly right. You may still have trouble getting circles to return
> to their starting point.
>
> If it were my project, I would implement circular moves as a sort of
> on-the-fly preprocsssor which segmented the arcs into short linear
> moves. Many programs use a cubic spline interpolator in their
finest
> trajectory planning loop, which means that the executed path is
> actually a lot more rounded thea the segments because it is fit to a
> simpler-to-caluclate curve through several points.
>
> In other words, because sine and cosine are expensive, you can
> calcualte them accurately at a few points and use a less expensive
> approximation to interpolate between those points.
>
> Chris Stratton
>
> PS - if it were me, I'd prototype the algorithm on a PC, plotting
the
> output on screen or as postscript or something to verify that it all
> works, before trying to get it running on the z80.
>
> -------------------------------------------------
> Christopher C. Stratton
> Engineer, Instrument Maker, and Horn Player
> ccs@m... 617 628 1062
> http://web.mit.edu/~stratton/www/brassbuild.html