Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Posted by
Jan Kok
on 2003-01-05 23:29:11 UTC
I suppose you want constant speed so that you chew up your workpiece at a
constant volume per unit time. However there are at least four other
factors that you might want to think about as you choose a speed. These
should only be a concern when the ellipse is very long and skinny.
- 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.
- 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!)
- Even if you move at constant speed, the acceleration is not constant - it
peaks at the ends of the ellipse.
- If your step size of theta is too large, you will have flat, polygonal
sides on the ellipse at the ends.
At any rate, since whatever calculus and DE brain cells I may have had have
mostly died, I would look for a less math-intensive approach to the problem:
pick an approximate step size for theta, calculate the new x,y position that
you are headed for, calculate the distance from where you are now to over
there, and if the distance is too far (i.e you are trying to go too fast),
just move an appropriate fraction of that distance, or if you have time (the
processor is fast enough), interpolate another value of theta and head for
that point. Or slow down the clock so the machine takes the appropriate
amount of time to get there.
BETTER YET!! Look up Breshenham's Algorithm on the net or in a computer
graphics book. It's how graphics hardware draws straight lines into
graphics memory, or controls an XY display. It's probably used in robotics
as well. The idea is that if you are drawing a straight line whose slope is
between -1 and 1, you go to the starting point, then take one-pixel steps in
the x axis. At each step you decide whether to keep the same y value, or
step up or down one pixel. This can be done with just an addition and a
comparison at each step - no multiplication or division needed! On the
other hand, if the line has a steeper slope than +-1, you step one pixel at
a time in the y direction and decide at each step whether to move the x
position.
Breshenham's algorithm can be adapted to draw circles - very nice, round,
smooth-looking ones, better than you can get by calculating points along the
circle with sines and cosines. As I recall (from implementing it once, long
ago) it takes some preliminary calculations to find where the circle has
slopes of +-1. While plotting the points, you only need about one
multiplication, one or two additions, and a comparison at each step. No
trig or square roots needed during plotting. It's very fast!
Apparently the algorithm can be adapted to work with any conic section
(ellipses, parabolas, hyperbolas), but I haven't gotten involved in the
details.
Enjoy!
- Jan
constant volume per unit time. However there are at least four other
factors that you might want to think about as you choose a speed. These
should only be a concern when the ellipse is very long and skinny.
- 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.
- 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!)
- Even if you move at constant speed, the acceleration is not constant - it
peaks at the ends of the ellipse.
- If your step size of theta is too large, you will have flat, polygonal
sides on the ellipse at the ends.
At any rate, since whatever calculus and DE brain cells I may have had have
mostly died, I would look for a less math-intensive approach to the problem:
pick an approximate step size for theta, calculate the new x,y position that
you are headed for, calculate the distance from where you are now to over
there, and if the distance is too far (i.e you are trying to go too fast),
just move an appropriate fraction of that distance, or if you have time (the
processor is fast enough), interpolate another value of theta and head for
that point. Or slow down the clock so the machine takes the appropriate
amount of time to get there.
BETTER YET!! Look up Breshenham's Algorithm on the net or in a computer
graphics book. It's how graphics hardware draws straight lines into
graphics memory, or controls an XY display. It's probably used in robotics
as well. The idea is that if you are drawing a straight line whose slope is
between -1 and 1, you go to the starting point, then take one-pixel steps in
the x axis. At each step you decide whether to keep the same y value, or
step up or down one pixel. This can be done with just an addition and a
comparison at each step - no multiplication or division needed! On the
other hand, if the line has a steeper slope than +-1, you step one pixel at
a time in the y direction and decide at each step whether to move the x
position.
Breshenham's algorithm can be adapted to draw circles - very nice, round,
smooth-looking ones, better than you can get by calculating points along the
circle with sines and cosines. As I recall (from implementing it once, long
ago) it takes some preliminary calculations to find where the circle has
slopes of +-1. While plotting the points, you only need about one
multiplication, one or two additions, and a comparison at each step. No
trig or square roots needed during plotting. It's very fast!
Apparently the algorithm can be adapted to work with any conic section
(ellipses, parabolas, hyperbolas), but I haven't gotten involved in the
details.
Enjoy!
- Jan
----- Original Message -----
From: "Todd Fleming" <todd@...>
...
> > f = _____________fo_____________________
> > SQR((COS theta)^2 + (SIN theta/R)^2)
> >
> > This will result in constant instantaneous velocity. Theta is the
> > angle which an equivalent circle would have (height = width), f is
> > the new clock frequency, R is the ratio of Width to Height.
> >
> > I haven't tried the frequency portion yet so I can't prove it OK,
> > but the numbers on paper work out.
>
> If I understand your equation, f = d theta / dt. Since I'm interested in
> theta as a function of t, this is a D.E. similar to the one I found; we're
> back to square one again.
>
> I tried finding a power series expansion of the D.E., but I can't find a
way
> to get the D.E. into a suitable form.
>
> > I would be interested in details of your requirement. What speed
> > will you run, what resolution, what ratio Width to Height, what is
> > your increment of motion?
>
> All of these are variables; I want to design a controller that can handle
> any reasonable variation.
>
> > Regards,
> > Jack C. Cain
>
> Todd Fleming
> flemingcnc.com
Discussion Thread
Todd Fleming
2002-12-27 18:35:47 UTC
Math for constant speed ellipse
Les Watts
2002-12-28 15:47:44 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Yesamazza@a...
2002-12-28 16:15:31 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Todd Fleming
2002-12-28 16:39:22 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Todd Fleming
2002-12-28 16:45:08 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Les Watts
2002-12-29 08:05:19 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Bill Vance
2002-12-29 12:09:12 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Les Watts
2002-12-29 14:56:29 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Todd Fleming
2002-12-29 16:51:46 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Bill Vance
2002-12-29 16:52:26 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
jcc3inc <jccinc@o...
2003-01-02 17:32:11 UTC
Re: Math for constant speed ellipse
Todd Fleming
2003-01-05 12:12:59 UTC
Re: [CAD_CAM_EDM_DRO] Re: Math for constant speed ellipse
Mariss Freimanis <mariss92705@y...
2003-01-05 18:00:59 UTC
Re: Math for constant speed ellipse
Jan Kok
2003-01-05 23:29:11 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Kevin P. Martin
2003-01-06 07:46:32 UTC
RE: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Nigel Bailey
2003-01-06 08:56:42 UTC
RE: [CAD_CAM_EDM_DRO] Math for constant speed ellipse - kepler?
Todd Fleming
2003-01-06 19:52:52 UTC
RE: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Todd Fleming
2003-01-06 20:16:10 UTC
Re: [CAD_CAM_EDM_DRO] Re: Math for constant speed ellipse
Todd Fleming
2003-01-06 20:33:51 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Todd Fleming
2003-01-06 20:45:19 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
Mariss Freimanis <mariss92705@y...
2003-01-07 02:25:25 UTC
Re: Math for constant speed ellipse
Jan Kok
2003-01-07 03:09:18 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
bjammin@i...
2003-01-07 07:16:30 UTC
Re: [CAD_CAM_EDM_DRO] Math for constant speed ellipse
torsten98001 <torsten@g...
2003-01-07 15:01:48 UTC
Re: Math for constant speed ellipse