LibLathe - Lathe Path Generation
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- dubstar-04
- Posts: 698
- Joined: Mon Mar 04, 2013 8:41 pm
- Location: Chester, UK
- Contact:
LibLathe - Lathe Path Generation
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/t ... ntegration
Facing:
Roughing:
Profile:
Part-off:
This Addon can be manually installed using the Addon Manager:
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/t ... ntegration
Facing:
Roughing:
Profile:
Part-off:
This Addon can be manually installed using the Addon Manager:
Last edited by dubstar-04 on Mon Jan 31, 2022 8:20 am, edited 13 times in total.
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Lathe Features
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.
- dubstar-04
- Posts: 698
- Joined: Mon Mar 04, 2013 8:41 pm
- Location: Chester, UK
- Contact:
Re: Lathe Features
I didn't think about the tool geometry and managing the control point.sliptonic wrote: ↑Tue Aug 28, 2018 10:20 pmNot 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.
- dubstar-04
- Posts: 698
- Joined: Mon Mar 04, 2013 8:41 pm
- Location: Chester, UK
- Contact:
Re: Lathe Features
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 Set Negative:
Retraction Set Positive:
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:
Code: Select all
retraction(0.0): Tool retraction absolute coordinate along retraction axis
Code: Select all
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
- Attachments
-
- PathLathe.FCStd
- (19.8 KiB) Downloaded 287 times
-
- LatheTest.zip
- (3.4 KiB) Downloaded 260 times
- dubstar-04
- Posts: 698
- Joined: Mon Mar 04, 2013 8:41 pm
- Location: Chester, UK
- Contact:
Re: Lathe Features
@realthunder what are your thoughts on this?realthunder wrote:ping
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Lathe Features
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.
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Lathe Features
Awesome! I'm thrilled to see someone playing with this.dubstar-04 wrote: ↑Tue Jan 29, 2019 10:38 pm I have been investigating what is possible for lathe code generation and I could use some help.
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.
- dubstar-04
- Posts: 698
- Joined: Mon Mar 04, 2013 8:41 pm
- Location: Chester, UK
- Contact:
Re: Lathe Features
Thanks for taking the time to look in to this and make a video!realthunder wrote: ↑Wed Jan 30, 2019 12:06 am 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.
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.
- dubstar-04
- Posts: 698
- Joined: Mon Mar 04, 2013 8:41 pm
- Location: Chester, UK
- Contact:
Re: Lathe Features
Hi Brad,sliptonic wrote: ↑Wed Jan 30, 2019 3:23 amAwesome! I'm thrilled to see someone playing with this.dubstar-04 wrote: ↑Tue Jan 29, 2019 10:38 pm I have been investigating what is possible for lathe code generation and I could use some help.
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 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
Re: Lathe Features
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...
1. 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.
2. 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/c ... log_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.
3. 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...
4. 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...
5. 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.
6. 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. 7. 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.
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...
1. 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.
2. 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/c ... log_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.
3. 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...
4. 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...
5. 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.
6. 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. 7. 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.
- Attachments
-
- LatheExample2.png (58.18 KiB) Viewed 16007 times
-
- LatheToolInsert.FCMACRO
- (23.69 KiB) Downloaded 326 times