Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse

From: "Todd Fleming" <todd@...>

> > - If you are milling around the outside of the ellipse, then you
> > will be chewing up a higher volume per time of material as you
> > go around the end than when going along the sides, if you go at a
> > constant speed along the ellipse that you are milling.
>
> Interesting; can you explain why this is so? Better yet, do you know
> of an approach that will chew the same volume of material per unit
> time? This would be much better.

If you hold the speed constant along the _inside_ edge of the path, then the
speed along the _outside_ edge of the path will be faster when going around
a curve, compared with going straight.

Consider a long flat ellipse. The regions close to the ends are very nearly
parabolas. For the sake of illustration, let's make an even cruder
approximation and say the ends are half-circles, say with a radius of 1/4
inch, and you are milling with a 1/4 inch diameter tool. So the distance
around the 1/4 inch radius semicircle is pi/4 inch, but the ring of cut
material has an outer radius of 1/2 inch and the area of cut material is
pi(R^2-r^2)/2 = 3pi/32 sq inches. But if you move the same pi/4 inches
along one of the nearly straight sides of the ellipse, the area of cut
material is pi/16 sq inches.

The solution to constant volume/time is to keep the _center_ of the tool
moving at constant speed, as long as the whole front half of the tool is
removing material (see next).

>
> > - If the center of your tool is tracing the ellipse, or if you are
> > milling the inside of the ellipse, and the tool width is a substantial
> > fraction of the minor axis of the ellipse, then as you come away
> > from the corner of the ellipse, you'll be cutting less volume per
> > time because some material has already been removed. (For a
> > proper inside cut, check that your tool radius is smaller than the
> > radius of curvature of the ellipse at the ends!)
>
> I have the same questions as above. I do see the problem that occurs
> that you noted in parentheses.

Suppose you are milling the _inside_ of the same long thin ellipse as above,
but you use a 7/16 inch diameter tool. At the point where the tool path is
perpendicular to the long axis of the ellipse, the tool is only removing
about half of the normal volume of material per time. As you back out,
obviously you are only removing about 1/8 of the normal amount per time.

Some reasons for trying to maintain constant volume per time is that that
keeps the force on the tool (perpendicular to the tool path, due to tool
rotation) constant. Thus the deflection (error) would be constant, and the
surface finish would be constant. It's generally not possible to maintain
constant volume/time throughout the path. So, if finish or accuracy is
important, make a first rough cut, then make a light finishing cut.

By the way, do you realize that if the inner edge of your tool path
describes an ellipse, the centerline of the tool, and the outer edge of the
tool path are not exactly ellipses?

> I'm trying for direct elliptical interpolation; the sides of polygon
> will be at most sqrt(2) * d, where d is the step size (or micro-step
> size) of the machine. I'm starting to realize this may be impossible
> for a constant speed. It worked out quite nicely for quadratics
> though; see my paper at http://www.flemingcnc.com/ .

It's a bit late at night for me to try to absorb it all, but it looks like a
nice bit of work :-).

You may not be able to control the speed with mathematical exactness, but I
think you can get pretty close. You just need to know the slope of the
curve you are tracing at each point. Let's say the slope is between -1 and
1. Then the time _period_ of your clock that drives your x stepper should
be proportional to sqrt(1 + slope^2). So you could issue an X step pulse
every 100 processor clock cycles when the slope is 0, but every 141
processor clock cycles when the slope is 1. I think you can see how to
avoid computing the square root :-)

> Do you know off-hand how much variation in speed Breshenham's approach

will

> produce when applied to circles?

Sure. When diagonal stepping, the speed is sqrt(2) times as fast as when
stepping horizontally or vertically. Is that what you mean? Or do you
mean, how does circle drawing compare to line drawing? I think circle
drawing was about twice as slow as line drawing, with both done in assembly
language. Come to think of it, I don't think I even needed to do a multiply
in the inner loop, because you can generate successive squares with
addition, i.e.:

0+1=1
1+3=4
4+5=9
9+7=16
16+9=25...

Are you using FPGAs? How fast is your FPGA or CPU instruction cycle time
compared to the minimum time between microsteps?

Cheers,
- Jan