Re: [Emc-developers] Cutter comp in xz

[Ray H. <re...@up...>]

On Thursday 12 December 2002 04:13 pm, Fred wrote:
> All,
>
> Ray wrote about cutter comp for a lathe:
> > I'm working on setting up an EMC for a lathe.  When I try to make a
> > move using g18 with comp I get the following error message.
> >
> > emctask.cc 245: rs274ngc_error: Cannot turn cutter radius comp on out
> > of xy plane
> >
> > I can see that most any milling cutter path will appear to be a
> > circle when spun around z and viewed looking at the xy plane from z. 
> > I can also imagine that there will be problems with the geometry of
> > the tool when viewed from any other plane.   Except perhaps in the
> > case of a ball end mill.
> >
> > It seems to me (been wrong before) that the same math used in the
> > mill example for xy would apply to xz when used with a lathe.
>
> I asked Tom Kramer our interpreter guy about this. Tom replied:
>
>
> The RS274 interpreter is built for 3-axis machining on a machining
> center. There are several assumptions it makes that are not correct
> for a lathe.
>
> My knowledge of lathe programming is skimpy, but I believe the axis
> of rotation of the part is normally the Z axis and radial motion
> away from the Z axis is considered to be along the X-axis (that's
> the way the diagrams for RS274/NGC show it).
>
> If we are talking about standard lathe operation (no active tooling,
> just cutting with the tip of a stationary cutter), and the cutter tip
> is kept in the XZ plane, and the cutting part of the cutter tip is
> effectively circular, and the controlled point is the center of tip,
> then the math for cutter radius comp in the lathe XZ plane will be the
> same as the math for cutter comp in the XY plane used in the
> interpreter.
>
> The simplest way to get the existing interpreter to work on a lathe
> is probably to leave the interpreter entirely as is and make the
> axis of rotation of the lathe be the X axis and the radial axis of
> the lathe be the Y-axis. If there are legacy programs, just replace
> Z with X and X with Y everywhere in the legacy program. Direct the
> output of the EMC X-axis controller to the rotation axis of the
> lathe and the output of the EMC Y-axis controller to the radial axis
> of the lathe.
>
> Alternatively, a lathe version of the interpreter could be written.
> This would be relatively easy to do if the lathe programs are all
> 2-axis programs. Basically, just get rid of all Z motion, then
> replace X with Z and Y with X everywhere in the source code.
> <<<
>
> Ray, will Tom's suggestion work for you?
>
> --Fred

Hi Fred.

I know of several folk who use the existing EMC to run lathes as Tom has 
suggested that it could be done.  I guess that I've always thought of 
this as a "make do until the real thing comes along."  I can just hear 
some of my shop owner friends singing the Mickey Mouse Club theme song if 
I tried to explain why my retrofits work differently than the rest of the 
lathe world.

Live tooling on a traditional lathe is way beyond my thinking here but 
the two axis approach is right on.  I am aware that some machine tool 
manufacturers are beginning to meld lathe and mill devices by adding tool 
spindles and extra axes.  

However, in the traditional lathe context, if I understand you and Tom 
correctly, we really need a second, lathe specific interpreter.  If we 
did the transform as suggested we could also remove those mill only codes 
and perhaps over time add some lathe only codes.  We could switch between 
interpreters using a variable in the [RS274NGC] section of the ini file.

Then we would add in Paul's suggestion that we need tool offsets in both 
(lathe) x and z as well as tool diameter.  This would require that we add 
a column to the tool file that is ignored by the mill interpreter but 
read by the lathe interpreter.  Would the existing interpreter ignore it 
if we simply added another column to the tbl file?

With these changes in mind, what would happen to the spindle code when we 
get into the task level.  Does the spindle stuff always refer to the next 
axis after those defined by the ini or is task going to get horibly 
confused when 0 is z and 1 is x?  

Ray