I am currently working on a python library to handle lathe path generation.
This is Experimental and for testing only
FreeCAD Addon for testing: https://github.com/dubstar-04/FreeCAD_Turning_Addon
LibLathe: https://github.com/dubstar-04/LibLathe
FreeCAD Integration: https://github.com/dubstar-04/FreeCAD/tree/LibLathe-Integration
Facing:
Roughing:
Profile:
Part-off:
This Addon can be manually installed using the Addon Manager:
Not really. I’ve experimented with a simple script that can build roughing gcode for a lathe but it’s hardly usable. Unlike a mill operation, a lathe operation needs to be smarter about the tool shape and collision detection.
@joshMorong has been working on some things that might help but nothing ready for prime time.
I didn’t think about the tool geometry and managing the control point. 
I have been investigating what is possible for lathe code generation and I could use some help.
I am trying to use Path.fromShapes to generate gcode and I am having some trouble with the ‘retraction’ parameter.
It seems the retraction plane can’t be in the negative direction, which is an issue for traditional lathes. At first I thought this was a bug but the description reads:
retraction(0.0): Tool retraction absolute coordinate along retraction axis
Retraction Set Negative:
Retraction Set Positive:
def getPathParams(start, shapes, retract_pt):
#print Path.fromShapes.__doc__
pathParams = {}
pathParams['start']=start
pathParams['shapes'] = shapes
pathParams['return_end'] = False
pathParams['arc_plane'] =1
pathParams['sort_mode'] = 0
pathParams['min_dist'] =0.0
pathParams['abscissa'] =3.0
pathParams['nearest_k'] =3
pathParams['orientation'] =0
pathParams['direction'] = 2
pathParams['threshold'] =0.0
pathParams['retract_axis'] = 0
pathParams['retraction'] = retract_pt
pathParams['resume_height'] =0.0
pathParams['segmentation'] =0.0
pathParams['feedrate'] =0.0
pathParams['feedrate_v'] =0.0
pathParams['verbose'] = True
pathParams['abs_center'] = False
pathParams['preamble'] = True,
pathParams['deflection'] =0.01
return pathParams
PathLathe.FCStd (19.8 KB)
LatheTest.zip (3.4 KB)
@realthunder what are your thoughts on this?
See below. There seems to be some recomputation problem in FeatureArea, you’ll sometimes need to manually ‘Mark for recompute’ of the area object as shown in the video. And yes, Path.Area currently do not support negative retraction. If that is really necessary, I can add it.
Awesome! I’m thrilled to see someone playing with this.
I suspect that the PathArea approach is inherently limited but it might be possible to get a basic rough turning operation to work. If nothing else, that would give us a reason to experiment with other job types and figure out how to organize the GUI.
Thanks for taking the time to look in to this and make a video!
I’m looking to you and Brad for guidance on this, but in my opinion having negative retraction on Path.Area() would be worth while if just for completeness.
I didn’t know you could use feature area like that. I will have a play and see where it gets me.
Thanks again for taking the time to reply. I know your super busy with other parts of FreeCAD so I really appreciate your help.
Hi Brad,
Thanks for replying. I was hoping you would be able to guide me a little with a good approach to developing some basic lathe tools, especially around the GUI side of things.
I have started adding some lathe ops to path but I’m thinking that I need to make some new base objects as everything is currently designed around milling.
I was starting to think that Path.Area() may not be best suited to lathe geometry but I didn’t know about FeatureArea shown above.
My current thought is to generate the path from commands generated specifically for each operation as this would allow better control of tool cutting direction and retraction.
I need to keep testing and develop the attached script to the point where it generates useable code before transferring the learning to path commands.
Thanks again,
Dan
Hi Dan,
Any progress on this? I noticed your post a bit ago, and have meant to touch base. In broad terms, lathe ops are easier than 4th axis milling, or 3d milling because the Job model is radial. But, the trade off is that the tool shapes no longer remain radial. My practical lathe experience is practically non-existent, but…
I’d recommend thinking about a triangular lathe tool insert as it’s the simplest, and best constrained example. Inserts appear an alternative to fixed tools, so if you figured out everything on an insert, it should translate to non-insert tools.
I played around with https://www.mscdirect.com/product/details/49418049 recently. I wanted to understand the code used to describe the insert, which I found on page 92 of http://www.ntkcuttingtools.co.uk/PDFs/cutting_tools_catalog_en.pdf I didn’t finish it, but started a script to generate based on code. It decodes the tool parameters generally, but only generates triangular inserts.
What becomes obvious is that the lathe operation tool shape is not adequately represented by a point in space. The cutting angle depends on the shank used to hold the insert, and the alignment of the shank to the stock. Assume the Y-axis “height” is fixed by the tool holder. This leaves X and Z axis movements, as you have been playing with. In theory, Y-axis should be adjustable, but not be able to be driven–that is, some lathe tools do not operate at Y = 0.0…
In the insert example I gave, the triangle has a nominal 11mm cutting-length, with 120-degree, 0.4mm nose-radius fillets at the triangle corners. The actual cutting length is less due to the nose-radius. The insert code I linked shows that there are various nose-radius and size options. This is just a typical example to work with…
I know from researching 3d cutting that a Ball-Nose milling tool interfaces to a Job-model surface such that the center of the ball is always at a point in space found by moving along the normal vector at the intersection-point on the model, a distance equal in length to the tools ball radius. This applies here too. The Ball is the 0.4mm nose-radius.
Here is a simple example of a lathe style job model. For our purposes, it includes flat, ramped, and interior/exterior fillets. If we do not calculate clearances, but only idealized points, the tool paths generated will cause the Job model to be violated.
Here is the sketch used to generate the model, and in construction lines, I show the Chuck–which must be cleared. I include it only for perspective because in the real world, it will be a significant consideration.
LatheToolInsert.FCMACRO (23.7 KB)
For “Along the Length” turning, the shank holds the insert at a fixed angle–30 and 45-degree appear common. Then, knowing the relationship of the shank to the work, defines the relationship of the insert to the work. If constrained orthogonal to the work–the relationship of the insert to the work is known the “Side Cutting Edge Angle”, and the “End Cutting Edge Angle”, described for the tool are true for the job.
https://www.mcmaster.com/3240a101
For clarity, I want to acknowledge that this is shown with the lathe turning around the X-axis, where the Z-axis is typical. Also, I am aware that I may be misleading between Left and RIght handed tool mounting, perhaps in part because I revolved the model from a profile sketch. Apologies for any added confusion.
I have drawn a Sketch of the example insert. It is aligned with the side cut at 0-degrees, which I believe is consistent with the style of shank linked above. Shown here, the nose-radius of the cutting tip of the insert is constrained, tangent to the “ramped” portion of the model.
Here, I have zoomed in on that, and added an “arrow” pointing to the tangent point between the insert and the job model. This highlights the question–what is the reference point for the tool? For milling, the reference is the tip of the tool, which is always aligned to the center of the spindle. Even when shifting from Square-Mill to Ball-Mill, the reference remains the same, though the toolpath must be offset vertically compared to square mill because the center of the ball is tangent to the job model, where the square mill requires an offset along the XY portion of the normal at the point on the model. Here, for lathe tools, the center of the ball should again be offset along the normal to the point by the radius of the ball (0.4mm in this instance).
I believe–but am not sure–that here too, the center of the radius of the cutting point is the reference point for calculations–that means that the generated tool paths should depict where the center of the radius of the cutting point travels.
Here, I show a path for this insert, that moves the center of the radius of the tool insert’s cutting corner. For this example, I drew it in Sketcher by hand. Note that I left space between the Chuck and the insert at that end. Note also that it is probably best to model the chuck–including jaws–as an axial/radial clearance. Where you want to move the cuts with precision, you want to avoid the obstacles with greater space, so modeling the chuck and jaws in detail is likely not helpful.
Note too, that in this example, the insert is in practice able to travel along all points of the finish cut line not constrained by the chuck. This is not generally true though because there are exceptions including, though not exclusive to: internal model surface that cannot be reached by the selected tool, grooving of the external shape that are too sharp for the selected tool.
I learned another thing I learned while examining 3d surface milling that should be of use to you. I looked at the extent a chamfer bit can interface to a sphere of cylinder arc. The answer is one of the many examples of what I consider “geometric beauty”. The chamfer tool angle cannot interface beyond the point where it is tangent to the arc. For a triangle with a 60-degree inclusive cutting angle, the angle between the center of the Job model feature’s axial radius, and the point of maximum allowable cut is 30-degrees. This is useful to determine the limits of the angles of Side-cutting that can occur along a more complex shape with axial arcs when the arcs are large compared to the tool.
While I did not do this here, the general approach could be something like:
The remaining edges can be extracted, then discretized by distance to generate points along the wires at appropriate intervals. For each point generated, the normal vector can be looked up or calculated. That normal vector (normalized if not already…), multiplied by the nose radius of the insert describes a point on the line you want to generate for your tool path. By iterating through the points on the edge, and generating points offset to the normal at those points, you can generate a list of points to create the path you want to cut.
This of course does NOT yet check for collisions with the rest of the insert and the rest of the job model. Here is a more complex model with opportunities for “axial” collisions with the insert or shaft.
And, below, we see one instance where the limit of the ability to cut occurs. The only option for the tool-path is from the point shown, moving toward the right–away from the chuck–is a line from the center of the cutting tip nose-radius to that reference at the
next turnable location where the insert can touch the model without violating it.
I believe that touches on some of what you are trying to accomplish. I’ll leave it there but if there’s anything I can help with, don’t hesitate to ask.
Regards,
Josh
Hi Josh,
Thanks for the information and explanations.
I spent a couple of weeks experimenting and seeing what I could do in FreeCAD. I’m now fairly confident I can create the lathe ops that I need:
I am now part way through writing a Python Library (LibLathe) to handle all the complicated parts and supply gcode to the FreeCAD Gui. The library is designed to be portable therefore doesn’t rely on any external dependencies, including FreeCAD.
This work is mostly done with the basis of the offset and clipping algorithms mostly working with a few edge cases still left to resolve.
I have written this myself as other offsetting an clipping libraries are more aimed towards milling strategies and don’t work well for lathe tool paths; one example would be recognising grooves and undercuts and removing these from the tool path.
This is an example of the profiling op:
There is a lot of refinement required but I think most of the complicated parts are worked out, for example the next thing I’m working on is continuing the roughing passes down the profile to intersect with the previous roughing pass to ensure that material removal is consistent for each pass.
What would really help is come bizarre and wacky models to test!!
Hi Dan,
Looks like you’re making good progress. I’m glad if anything I offered is helpful. I’ve put a fair amount of thought and effort into understanding the relationships that exist between cutting edges and job models, so figured if any of it translates and is helpful to you, I’d throw it out there.
I see that you’ve worked out the issue where a feature of the job model is too small to fully achieve with the selected tool. That’s a big one. It looks like you are approximating the cutting edge as a single point though, unless I’m mistaken, and that likely will require further refinement–which I believe you alluded to.
I’m not sure the tool model that you target in the last image you posted. If it is similar to the insert that I mentioned, and the triangle of the insert is capable of side-cutting tangent to the edge of the “base of the pawn” in your model, I believe your path is good up to the intersection to the sphere at the “top of the pawn” in your model. The issue may occur where your path appears to be supporting both left-justified and right-justified–that is, it is tangential to the model on both sides of the sphere.
But, as I mentioned earlier, I believe it is key to understand the reference point of your tool. So, where I mention an offset due to the nose-radius curvature on the tool I used as an example, your path is drawn for a sharp tool with no nose-radius. That’s a valid tool that requires support also, so I don’t mean to imply what you have is in any way wrong, but am trying to get a sense if you have already considered (or implemented) support for tools with a nose radius, or with cutting edges other than 60-degrees for that matter.
I think you made a good choice to ignore completely grooves/slots that are not entirely turnable with the current tool. I am not sure, but believe, that you would generally shift to a different tool for special operations, and allowing your algo to try to “rough” into that might be more trouble than it’s worth.
You mentioned working out boring, versus other turning ops, and that implies that you do–or want to–support more complex models that might contain both interior and exterior turning. Do you intend to support models that are intended for lathe operations on some portion, but milling on other portions? That is, if there is a flat section on an otherwise “turned” model, is your algo still good with it, or will it stumble on that?
I think another area often overlooked is the significance of the Chuck in how close you can get to your model. I believe that tailstocks are of limited use in CNC lathe work, because of interference with the tool-table, but I’m not sure of that. The chuck jaws on the headstock though can be challenging. You need to grab the stock well, and the further away from it you are, the more need for tailstock support. The closer you work to the Headstock though, the less clearance available…
I’ll try to work out some models for you. Do you require models be generated in a certain plane? Are you at a point where you can share your existing inputs/assumptions, and/or script? Asking only to get a sense what you are looking to evaluate. Everything’s radial cutting, and we’ve discussed some of the more obvious challenges, so I’m curious what you are looking to validate?
Any input is helpful and to be honest i’m generally happy that someone is interested enough to discuss it at all, where as you have clearly invested lots of thought and effort in to the thinking.
what I have done is still very much proof of concept. I have a plan that I am working through but I am a way off completion.
The only concept of a tool currently in my library is an allowable cutting angle. I generally use DCMT inserts on a RH tool with an angle of 60 degrees so the ‘undercut’ on the screenshot would be possible with that tool.
The tool is currently not represented in the code so there is no consideration for the radii or offset. If you don’t mind I would like to use some of the code from your macro to form part of the tool class?
Other CAM software allows ‘partial grooving’ where the tool will cut wherever it can reach. I would like to support this feature but its not something I use myself. Like you say I prefer to do all the grooving with a proper grooving or parting tool.
Yes I intend to have a boring op because I need it. I do fee earning work on my machine and almost every part I make has some type of boring.
When working on mill/turn parts the library expects that the part has been simplified before being passed in to the library. This will require some work to the job setup in FreeCAD to ‘spin’ the profile of the part and ensure that the outer profile or extremities are passed in to liblathe. This would certainly be something that would benefit from your attention if you fancied looking in to it?
The UI I have been testing allows setting the inner and outer profile limits and the end plane limits. This allows manual adjustment to account for work holding and addition offset / lead in / lead out.
I was toying with the idea of including a chuck plane too as additional check. This is a feature available in my current CAM software and it can be useful.
I am just looking to test with different models to check that I have considered as many different scenarios as possible. I am currently working through some edge cases where models have axial grooves (grooves in the z direction) and undercuts.
The only requirement for the model is that it the z direction can be set correctly in the Path Job setup, this is another area that requires some attention. Some models have to manually rotated to achieve the correct model setup.
There isn’t much mileage me sharing what I have at the moment as I know that it won’t work everywhere (plus the code is a mess!!) I am almost at the point where it is worth me pushing it to my GIT account to track the changes a bit better so once that is done I will share.
Thanks,
Dan
Hi Dan,
Not sure what code interests you, but you’re very welcome to anything I can offer. I have essentially zero practical lathe experience–limited to turning small parts in my CNC spindle. It is a fascinating endeavor you’ve taken on, and I’m happy to bounce ideas if nothing else.
Something that occurred to me was if/how you intend to support threading, or helical cuts, if that’s even possible in the context of CNC lathe. My question on that regard is 3-fold: is it even possible, if so do you support the operation, or do you ensure those features on a completed model do not trip up your code?
I had asked you about tool-reference because–though I don’t know this–it seems like an important consideration. Where in CNC milling, everything is spindle-centric, it seems like lathe differs a bit. So, for example, with a lathe op, the relationship between the tool cutting tip, and the work could shift if you mount the tool in a different height tool holder. If it were an insert and placed in different shanks, with differing cut-angles, by the mounting angle of the shank/tool-holder/tool-table, etc… I am pretty sure that some of this is typically done by changing offsets in the CNC controller, so that the relative offsets between the cutting-tips of the various tools mounted on the table all touch at the same location on the work when fed that position in GCode. Where on CNC mill, I can measure or touch off the tool tip to “zero” the Z axis, and similarly can use homing switches to zero the XY of the machine, with lathe, you could do similar, but I suspect there is more “make a cut, measure it, adjust” in play. And, if homing/zeroing is common, how is that done since not all tools would cut at the tip, so it’s not a simple touch-off plate is it? Also, depending on the degree of larger error/collision checking with shanks, etc… does it make sense to reference to the mounting screw-hole, or location where it would be if clamping insert?
Also, I’m aware that for some lathe operations, it is typical to slave the Z-axis to the rotation of the stock, using G94, to allow for threading, for example. I’m curious your thoughts on where, in the “design chain” this is partitioned. Is that a post-processor sort of thing, or is it done on the machine, or is it important in the operation?
I’m also curious your thinking on whether in long run, the nose-radius of the cutting edge is a significant consideration within the path-generation portion of work-flow? Put another way, would a working machinist consider the change in tool shape or is it minor?
Hi Dan,
Attached is a model representative of a typical mixed lathe/cnc job, to play with.
It’s largely a lathe job, but has other features that make it not entirely symmetrically radial.
Best,
Josh
lathe_job_0.FCStd (401 KB)
Hi Josh,
Sorry for the delay in response. I was working away last week and then took the kids camping at the weekend.
I will likely write the tool code tonight and i saw that you had written a tool class with the tool parameters. This is likely something I can use.
Threading is definitely possible. Most controllers support canned cycle threading like a G76. These usually need some work in the post processor but it should be pretty straight forward to implement a threading op.
This is a huge subject and no doubt every person you ask will have a different method for setting up tools. In principle it is basically the same procedure for a lathe as a milling machine. i.e, you record offsets for tools compared to tool 0.
The controller then handles the offsets for each tool.
The x axis is generally considered to be at zero when then tool is on the spindle centreline.
The Z axis can like a milling machine can be zeroed anywhere.
My lathe has homing switches to reference when it starts up. The coordinates are then relative to the homed position, as a milling machine.
It might be easier if I made a video about setting up the machine rather than trying to explain it. on my milling machine I use a height gauge for the tool offsets and this is a concept I really struggled to grasp until I had actually done it myself.
Its similar with the lathe it can seem complicated until you try it.
I currently cant think of a situation where this could be useful.
Not sure I understand the question. My lathe has a spindle indexer that knows the rotation angle and speed of the spindle. It uses this to control the threading operations and for RPM feedback.
The surface speed is then calculated from the X position and the spindle RPM. Is that what you mean?
I think the radius of the tool will be important to understand the capability of a tool.
Thanks,
Dan