CAD CAM EDM DRO - Yahoo Group Archive

Re: Re: Re: Cutting a totem Pole

Posted by Ray Henry
on 2002-08-07 08:09:10 UTC
>    From: Matt Shaver <mshaver@...>
> Subject: Re: Re: Cutting a totem Pole
>
> On Tuesday 06 August 2002 05:23 pm, Fred wrote:
> > It is
> > rumored that EMC will contour more, but I heard it on a pretty good
> > authority today that the source for this might be "missing". ( If
> > anyone knows where the 6 axis source version of EMC is located,
> > please post it. thanks)

Hi Fred

I think what might be missing is a bit of code to implement
CANON_WORKPIECE or at least the g-code to call it so that it will compute
the feedrate of the tool tip during a five axis move. If there is no
computation of this during cutting, the EMC interpreter code mentions
that it would need to be done off line and included in the part program.
If Vector does this for you during the writing of a g-code file then it
would be no problem.

Hi Matt

<s>I don't know if the regular steppermod or freqmod modules
> have axes 5 and 6 mapped to any output pins. If not, it shouldn't be a
> big deal to add them. The latest version of the interpreter supports
> six axes.

Yep. They are all in there and you can watch them work with the IO_Show
script.

There was some recent talk about helical millling in this context. I'm
not certain that this really qualifies as four plus axis contouring. It
can easily be imagined with three axis commands with a circle being
milled in xy and the helix as a simple linear z move. A similar sort of
path can be created with a rotary fourth axis but that is also a simple
program to move the tool into position and then rotate the part. The
difference here is that the feedrate becomes degrees per minute rather
than linear units per minute. To translate degrees per minute into
feedrate you need to know the distance between the fourth axis locus and
the tool tip as Rab pointed out a bit ago.

Feedrate in four axis contouring I can kinda visualize because it is a
lot like constant surface speed on a lathe. I could even write some g
code code for it but this real five axis stuff where one rotary axis is
stacked on another is gonna require some kind of an altered state.

IF the six axis Cartesian space is fixed in relation to the machine's
x,y,z then once you rotate #4 away from perpendicular to x, y, or z,
motion of the second rotary becomes a combination of #5 and #6 in
Cartesian space. At this point an automatic tool tip feedrate begins to
move away from the lathe model. At least the lathe model gets skewed by
the compound motion. What we need is a cutting surface vector (not the
cad/cam) that get apportioned out to each axis by some set of trig
equasions. (We do this with matrix computations in the EMC for for
Hexapod and robot kinematics but I think it is the reverse of the
feedrate problem.)

Now toss in the geometry of a non-cylindrical cutter -- a ball mill is
the easiest to imagine. If the z axis is perpendicular to the work then
at the very bottom of the ball, there is no, or almost no cutting. The
tip must be below the surface so that material is removed somewhere up on
the side of the mill and less and less material is removed as material is
forced sideways into the tip.

Now move x, y, z so that the ball is cutting on it's side and you have a
very different set of constraints. This way it is acting like a simple
mill unless you're trying to hog a lot of material. Somewhere between
these two extremes is where five axis milling will most often take place.
With this configuration, unlike the lathe's constant surface speed, or
the constant vector cutting speed we imagined a bit ago, we need a new
construct which is a value for the interaction of the cutter geometry and
the motion geometry.

It seems to me that one more complexity intrudes and that is the geometry
of the surface being cut. So far I've been thinking of a flat surface or
at least flat at the point where cutting is taking place. This will be
true if the surface is flat or convex. What happens when the surface is
concave and cutting is taking place across an arc of the surface of the
cutter. We would have to somehow average the feedrates computed by the
geometry or take the slowest.

But then reality intrudes 'cause Frank is already sitting in his air
conditioned kitchen, drinking a can of the braumeisters finest while
watching his 3 axis machine out there in the Florida hot making piles of
money doing contouring. He probably has his stereo going and computes
things in parts per minuet.

Perhaps I should ask my pharmacy for help.

Ray

Discussion Thread

vrsculptor 2002-08-06 11:42:46 UTC Cutting a totem Pole caudlet 2002-08-06 12:06:28 UTC Re: Cutting a totem Pole imserv1 2002-08-06 14:23:14 UTC Re: Cutting a totem Pole allan_reinhard 2002-08-06 14:28:33 UTC Re: Cutting a totem Pole vrsculptor 2002-08-06 16:14:52 UTC Re: Cutting a totem Pole rainnea 2002-08-06 16:55:08 UTC Re: Cutting a totem Pole allan_reinhard 2002-08-06 17:13:32 UTC Re: Cutting a totem Pole Matt Shaver 2002-08-06 20:43:17 UTC Re: [CAD_CAM_EDM_DRO] Re: Cutting a totem Pole Les Watts 2002-08-07 07:30:11 UTC Re: [CAD_CAM_EDM_DRO] Cutting a totem Pole Ray Henry 2002-08-07 08:09:10 UTC Re: Re: Re: Cutting a totem Pole rainnea 2002-08-07 23:58:22 UTC Re: Cutting a totem Pole Ray Henry 2002-08-08 13:26:47 UTC Re: Re: Cutting a totem Pole rainnea 2002-08-08 13:52:04 UTC Re: Cutting a totem Pole Jon Elson 2002-08-09 20:24:50 UTC Re: [CAD_CAM_EDM_DRO] Re: Cutting a totem Pole