Re: Cutting a totem Pole

Is it possible to drive more than 4 axes from one parallel port with
EMC ?

For calculating 5-axis feedrates I find the distance of each move
from the toolpath as it's being exported. The toolpath is a spline,
so the distance for each move is the length of the spline segment for
each point. As the spline is subdivided into lots of very small G1
movements I can ignore any additional arc distance as being
insignificant. The feedrate from distance calculation is then exactly
the same as for 4-axis.

I generally keep the tool perpendicular to the surface being cut, but
I'll need to try leaning it towards the next point on the toolpath to
see how much of a difference it makes to the efficiency of cutting.
I'm thinking of say 15 degrees for a ball nose cutter, can anyone
recommend a better value ?

As Fred mentioned, gouging can be difficult to avoid and a means of
simulation would be welcome to double check for this.

Rab

--- In CAD_CAM_EDM_DRO@y..., Ray Henry <rehenry@u...> wrote:
>
> >    From: Matt Shaver <mshaver@e...>
> > 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