Proposed OT lathe coordinate system

#1
In doing the OT simulator software, I choose the following coordinate system to describe the OT lathe:
  • X - front to back, positive to the rear
  • Y - vertical, positive up
  • Z - left to right (headstock to tailstock), positive to the right (towards the tailstock)
I an email from Bill Ooms, he suggested the same interpretation of Z, also with X front to back and Y vertical, but with the +/- directions of X and Y both reversed. (Both of these systems are right-handed coordinates, just turned 180 degrees on the Z-axis).

The Z+ direction makes sense, as this produces a positive direction (counter-clockwise) for the normal headstock rotation.

In thinking about the other two axes, the only factor that comes to mind is the operation of the slide rest.

I've received my copy of "Ornamental Turning" by J.H. Evans and have just read Chapter X, "The Ornamental Turning Slide-rest", which confirms what I thought.

The main point is that the slide rest can be set at different angles to either "turn the cylinder" (as Evans puts it) where it is parallel to the lathe bed, or "turned to the surface", where it is perpendicular to it. If we start with the SR set parallel to the lathe bed, we could turn it 90 degrees in either direction to get it perpendicular. But turning it in a counter-clockwise direction means that we don't need to spin the toolbox around 180 degrees to point off the other side of the SR. This also means that the end of the SR pointing in the Z+ direction (the end with the handcrank) now points towards the back of the lathe. This argues for X+ being towards the back of the lathe.

As a smaller point, Evans states (pp 42) that the angle of the slide rest is set to 0 when the slide rest is parallel to the lathe bed, and 90 degrees when perpendicular. Thus this counter-clockwise rotation is considered to be a positive angle on the SR dial. This would suggest that Y+ should be up (in a right-handed coordinate system).

So both of these factors suggest X+ to the rear, and Y+ up (given that Z+ is to the right).

Since I am still very new to OT work, I'd like to hear from those more knowledgeable than myself as to whether this makes sense, as well as whether there are other factors which I have not considered?

-Bruce
 
#2
Here's the excerpt from my earlier email to you:

I recommend that you edit your programs to use the following conventions: Z is in the direction of the axis of the lathe spindle, with +Z being toward the tailstock of the lathe; X is essentially the radius with +X being toward the person when standing in the normal position in front of the lathe; (and when Y should be added, +Y would be down according to the convention of right-hand coordinate systems); C is rotation around the Z axis with +C being counter-clockwise when looking toward the chuck from the tailstock . I had used different notation, but Dewey and Jon beat me up about it pretty badly. So after the OTI symposium in September I took a few weeks to re-write the software using the above conventions.

The reason I chose +Z toward the tailstock and +X toward the "front" is because the majority of time we are mounting turned objects on their base (or bottom). When we look at a profile of a piece of work (or look at the finished product) we tend to expect + to be toward the right and up because that's what we learned in math ever since grade school.

You can go with any coordinate system you want, but this is what I'm staying with.
 
#3
Thanks Bill!

We're in agreement about the right-handed coordinate system, which are the X, Y and Z axes and which direction Z+ is. And I think for the same reasons.

I'm not sure I understand your X+ argument. Seems like the work is symmetrical so once we have the work on the table with Z+ up, turning the work 180 degrees wouldn't matter. Am I missing something here?

Dewey and Jon, I'm OK with being beaten up publicly in the forum. I figure if I'm confused, I'm probably not the only one; so it would be good to document the reasoning so that we can all benefit. So don't be shy!

Thanks again Bill. You've been very patient, and a big help!

-Bruce
 
#4
You need to think in terms of how you will present information to the user and the graphical interface. Again, people are accustomed to + being to the right and up. When you present the user with a graphical view of where the cutter is relative to the work piece, they will think in terms of a + value being to the right of the work piece and a - value being to the left of the work piece. See my RESurface software and you'll understand what I'm talking about.

Machines don't care about the +/- convention, nor do computers. You can program them for any coordinate system you like. But people have some expectations when they look at the human interface. When they set a cut location to X=2.0 I think they will expect it to be toward the right of the work piece as viewed on the display. When they look at the piece on the lathe from above and turn their head a bit to the right so as to see the orientation of the piece in the same orientation as they see on the display, then they'll expect the cutter to move toward the front of the lathe to correspond to what they see on the screen. There may be a few people who feel comfortable with the concept of imagining the work viewed from the bottom of the lathe, but probably not many.

The one thing that will definitely confuse people is if they see a cutter moving to -2.0 on the EMC display (or Mach3 or whatever) when the screen shows a cutter location of +2.0.

As I said earlier, this is based on the observation that most work is mounted on the bottom while being turned. On those few occasions when you chuck the work on the top (i.e. to finish off the base) then things will necessarily be backwards.

Just my opinion. It's OK for others to do things differently.
 
#5
Does it really matter? Surely so long as we write software that is configurable the user can mould it to suit their needs. So if they want the spindle axis to be X and moving from right to left they can.

I admit I am not yet at that position as I let the user decide which axes to use and this affects the gcode generation, but my displays are fixed to left to right for increasing values, but I will be working on it.

I see it as mostly just adding another transformation to the display pipeline. Of course the standard internal model the user does not neccessarily see is up to you. What the user sees is just a transformation of this internal model and that transformation may be the identity or may be another that say switches the direction of the standard axes (which includes going from a left handed to a right handed system if necessary). Its all just a matrix anyway.

I am willing to be corrected but thats my current view

Alan
 
#6
Sticking with convention as Bill suggests makes it a lot easier for someone to move from another field such as metalworking into OT. If you come up with your own system many will start their journey in confusion.

Does it matter to the computer? No. That said, if it makes no difference why not reference it to convention.

David
 
#7
Sorry everyone, :oops:
Re-reading my last post I realise it came out much much more strongly than my intention when writing it. I was really just posing the question but much more mildly than the tone of my posting suggested. Accept this as my silly mistake for this year.

I accept that common practise is necessary and helpful it was a plea to make software responsive so that everyone can work in their own particular way.

Alan
 
#8
One further thought about axes

It would be my inclination to use separate sets of axes for the work and the cutter. So say XZC for work UWB for cutter. I think that this avoids muddying the waters when the cutting tool is travelling directly in the opposite direction to the work. When moving into the face work movement along X and tool movement along U (can we make U point along -X) etc. We then do not need to subtract the current cutter depth from the X movement to get the correct position. What do you think?

Alan
 
#9
Alan --

That's a good question you raise about using a separate axis for the cutter. I don't yet know enough about g-code to give an opinion.

However, here's a related question that may be unique to OT work: With the g-code that we write, should we output the XZ coordinates of the center of the cutter? Or should we output the XZ coordinates of the work surface and specify the radius of the cut in a tool table? So far, I've been outputting the XZ coordinates of the cutter and I specify that the origin of the cutter is the center of the inscribed cut. For UCF and HCF this is the center of the axle and for Drills this is the center of the tip. I was about ready to make some changes and start using the Tool Table, but it occurred to me that it might not work for UCF cuts done at an arbitrary rotation. For example, lets say that the UCF is rotated by 45 degrees on it's shank, and the shank is aligned with the bed of the lathe (i.e. parallel to the spindle). If we are cutting on a dome-shaped lid of a box, then the "radius" depends on where the tool is located on the dome-shaped surface of the wood. On the very top of the dome, the radius is the actual radius of the cutter. But as you get further around the side of the dome, the effective radius of the cutter is less. I don't think you could use a single tool diameter and expect EMC to calculate the correct cutter radius compensation. (see the graphic below)

I'm not sure how you would use the Tool Table in this situation. I'm not sure if this situation arises in traditional CNC machining. Would a local UWB axis for the cutter help in this situation?

 
#10
Bill,
I'm afraid that I do not know how to answer your question. Everything I have done so far just assumed that the origin of the cutter coord system was at the tip of the cutter and on its axis of symmetry. But unlike yourself, I have only been concerned with the path of the cutter and not with a realistic display of the shape being cut.

I only know that for me the path displayed in the emc pre-plot is the actual path in space of the cutter tip. Emc automatically takes any UVW axis movement into account when displaying its path. But of course it does not show how the radius of the actual cut changes.

By the way to attach an image use either the Img or g2Img button if using the forum form. Or if emailing from your mailserver perhaps you can use
"
" for a standard url or
"
" for a gallery item where xxxx is the id of your image in the gallery. But I havent yet tried typing these in directly myself. Also I found that the gallery image is downloaded at full resolution into the mail message not at the smaller resolutions displayed in the gallery itself. I have yet to find out how to alter this.

Alan
 
#11
Thanks for the reply. Also thanks for the tips on adding images. I edited the prior post and got the image to appear.

I'll have to ask Dewey the next time I talk with him. (Although I think he is mainly using end mills, etc. and not using a UCF.)
 
#12
Re: tool radius compensation

Bill,

Not sure about EMC, but the Tormach machine at the Fab Lab does not recommend using the cutter radius compensation feature. But the Tormach uses Mach2 and I don't know the differences between Mach2 and EMC2.

From the Tormach manual:

Important note: You need to be aware that cuts inside a shape which have detailed moves in the G-code smaller than the compensation being applied are unlikely to be cut as you expect and hope. The control software is limited in how far it looks ahead and so may discover when it gets to a particular move it has already cut too far (gouged) the profile. In this case you need to use CAM generated code which calculates the correct path for the tool to follow.
Cutter radius compensation is specified with G40, G41 and G42 codes in Mach2.

-Bruce
 
#14
Re: tool radius compensation

Bill,

The short answer is yes, I've had to deal with tool radius offsets manually while setting up each run. I have never used the cutter radius compensation provided by mach2.

To me, this seems like the last area (not counting GUI) to figure out for this simulator software. The way I've handled tool radius offsets in the two projects that I've done so far seem both messy and like "cheating" in that neither case used a nice general solution based on some nice "theory of offsets". Rather, each solution felt more like a kludge that would only work in each of these specific situations.

I expect that the treatment of these offsets would be a big difference (software wise) between the "automatic" and "manual" modes of CNC operation. I would think that in the "manual" mode of operation, the user would generally incorporate the tool offset by eye so that the software doesn't need to deal with it. But I have not had the chance to try manual operation yet, so haven't been able to confirm this hypothesis.

If you gain some insight into how the software should handle these offset issues, I'd be very interested in hearing it!

The details of the two approaches that I used follow.

For the vase project, I added a tangent angle output to my virtual elliptical chuck. The reason is that normally the ellipse would be cut with an HCF and a pointed cutter so that the tool offset is simply fixed at the radius of the HCF. But with a tapering ellipse, this is no longer the case. By adding the tangent angle as an output of my virtual ellipse chuck, I could use a VCF instead to cut the ellipse. Then I didn't need to worry about the slope of the taper. But I didn't have a VCF, so used an imitation by cutting on the end of a straight router bit. So imagine a straight router bit held in a drilling frame with the tool shank parallel with the lathe's X axis. Then, as the ellipse chuck rotates, I change the angle of the tool shank (a rotation on the lathe's C axis) to keep the tool shank perpendicular to the tangent of the ellipse. To do this rotation, I have to use the center of rotation at the end of the tool as the zero point so that the rotation doesn't move the end of the tool. Then I have a post-process "offset" function that moves the tool along the lathe's Z axis by the tool radius. The movement is either + or - depending on which edge (left or right) I'm cutting on (which depends on the slope of the taper, + or -, which I just took as a fixed offset point on the SR). Note that this trick can not be done with this tool on an XZC machine, because the machine is not capable of changing the tool's angle against the work. An XYZC machine can do it by moving the tool up or down, which changes its angle to the work.

For the fluted elliptical dome project, I knew I was using a ball end mill on an XYZ machine that could not reproduce these tool angles. The way I cut the dome was to use a dome chuck on an ellipse chuck. Each flute (over the top of the dome) is cut as an ellipse (by the ellipse chuck) where the semi-major axis depends on the nosewheel index of the dome chuck, and the semi-minor axis is fixed at the height of the dome. Having the tangent angle output from the ellipse chuck, I again tilted the tool shank to keep it perpendicular to the surface of the work. Again, I used the center of the tip of the ball end mill as my zero point so that the end would not move with this rotation. Then my post-process "offset" function simple pulled the virtual tool back along the tool's shank by the radius of the cutter to get the offset. These rotations of the tool's shank were lost when going to the XYZ machine, so I needed to reset the machine coordinates on the CNC machine so the tool's zero point was the center of the ball (i.e., at the center of the sphere, rather than it's tip). Since the tool is always vertical on that machine, I simply added the tool radius as an vertical offset. Thus, when the tool was at a different angle, it was at a different angle relative to the center of the spherical ball at its end, which would cut the same flute regardless (within limits, which I did not exceed).

-Bruce
 
#15
Re: tool radius compensation on dome ellipse

In giving this more thought, I realize that I mis-stated how the tool offset works in the dome ellipse piece that I did. This post corrects that with several diagrams. If you are not interested in how the tool offset was done for the dome ellipse in the OT simulator software, you can safely skip this post!

I had mistakenly said that the position of the tool "center" was changed during the tool offset process, but this was incorrect. The tool center (or zero point) is always the center of the semi-sphere on the end of the ball end mill. This center is indicated in the following diagrams by a small red circle.

First of all, the dome ellipse is cut on a dome chuck, which is attached to an ellipse chuck. The ellipse chuck lets us cut flutes over the top of the dome. The flutes (at least the bottoms of the flutes) are elliptical, when viewed from the side, hence the ellipse chuck.

This first diagram shows how the virtual ornamental lathe is configured at one point along the cut. This view is looking from the tail stock back towards the head stock. The long vertical and horizontal lines across the center of the diagram indicate the center of the lathe (center of rotation of the headstock). The small offset blue circle is the path that the nosewheel of the ellipse chuck takes. The tool starts out horizontal pointing into the work with the tool center at the point where the cut is desired.



The first tweak is to rotate the tool so that it is perpendicular to the surface of the ellipse.



Then the offset is easily done by simply pulling the tool straight back on its Z axis (this is the line through the length of the tool).



Now this arrangement of the tool in relation to the work is taken to the XYZ CNC mill. This should look as follows:



But this CNC mill has no rotation axes, and so can not reproduce the tool rotation. The CNC machine is given the XYZ location of the tool center, so that the tool ends up as shown, which will still cut the desired flute:



Sorry for any confusion. Hope this helps!

-Bruce
 
Top