Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)
Hi,
this came out of a longer discussion in the help section on using ball-end tools on 3D-surface. Firstly it is great that this path tool supported ball-end cutter, attempting the same cut with a straight tool would require hours of microscopically fine cuts and would still not be that satisfactory in finish.
However, the fact the cut paths alternate in direction means that no account is being taken of climb vs conventional cutting direction. The result with the ball-end cutter is quite marked. There is an obvious need to be able to control the direction of cut. Since this tool is either X or Y derived paths it would presumably be relatively simple to always work in the same direction and give the user control of this.
In this relatively trivial geometry it would require a reversal half way through. But since the software must know which side of the tool is in contact this cannot be too much of an obstacle.
This is also an issue on many of the other tool paths where often only Spiral offers a consistent cut direction. Sadly this is one of the least reliable path options. I have posted about various problems with Spiral and I think this is a well known issue. Perhaps the fact that it is often the best choice for attaining consistent cutting would merit it getting some attention.
Climb vs conventional is a really basic machining requirement not an optional extra. The climb cuts here produce a good, clean finish. If it were possible to cut in one direction it would have produce a very nice result.
It was suggested that I post this here.
BTW the groove at the bottom was done by direct Gcode to remove the residual due to tool width on a previous use of a straight tool, it was not a result of 3Dsurface path.
this came out of a longer discussion in the help section on using ball-end tools on 3D-surface. Firstly it is great that this path tool supported ball-end cutter, attempting the same cut with a straight tool would require hours of microscopically fine cuts and would still not be that satisfactory in finish.
However, the fact the cut paths alternate in direction means that no account is being taken of climb vs conventional cutting direction. The result with the ball-end cutter is quite marked. There is an obvious need to be able to control the direction of cut. Since this tool is either X or Y derived paths it would presumably be relatively simple to always work in the same direction and give the user control of this.
In this relatively trivial geometry it would require a reversal half way through. But since the software must know which side of the tool is in contact this cannot be too much of an obstacle.
This is also an issue on many of the other tool paths where often only Spiral offers a consistent cut direction. Sadly this is one of the least reliable path options. I have posted about various problems with Spiral and I think this is a well known issue. Perhaps the fact that it is often the best choice for attaining consistent cutting would merit it getting some attention.
Climb vs conventional is a really basic machining requirement not an optional extra. The climb cuts here produce a good, clean finish. If it were possible to cut in one direction it would have produce a very nice result.
It was suggested that I post this here.
BTW the groove at the bottom was done by direct Gcode to remove the residual due to tool width on a previous use of a straight tool, it was not a result of 3Dsurface path.
- Attachments
-
- 3Dsurface-detail.jpeg (443.97 KiB) Viewed 2226 times
Last edited by Kunda1 on Mon Sep 02, 2019 4:51 pm, edited 2 times in total.
Reason: Updated thread title
Reason: Updated thread title
Re: climb / conventional
The person you want to talk to is realthunder, but he's probably quite busy these days with the Link merge. I had never good results from Spiral and my goto pattern is Offset, much more stable, not as efficient but the cutting direction is also constant.freman wrote: ↑Mon Sep 02, 2019 5:24 am This is also an issue on many of the other tool paths where often only Spiral offers a consistent cut direction. Sadly this is one of the least reliable path options. I have posted about various problems with Spiral and I think this is a well known issue. Perhaps the fact that it is often the best choice for attaining consistent cutting would merit it getting some attention.
PathSurface is an entirely different beast since it's based on OCL. I don't think anybody here has started to look at the implementation of OCL (I would be rather excited if I'm wrong). So any functional changes/feature requests probably need to be reported upstream.
Re: climb / conventional
Thanks for the reply. I will look again at offset as you recommend for planar cuts.
I knew that 3D tools were using OCL but I guessed it was to work out the geometry at a lower level. I did not realise it was responsible for the entire tool path. Since you tell me that OCL is where the alternating path directions are created, I will see whether I can raise this upstream.
Great to see realthunder's Link work is finally getting merged. I may try to get his attention when the dust has settled.
I knew that 3D tools were using OCL but I guessed it was to work out the geometry at a lower level. I did not realise it was responsible for the entire tool path. Since you tell me that OCL is where the alternating path directions are created, I will see whether I can raise this upstream.
Great to see realthunder's Link work is finally getting merged. I may try to get his attention when the dust has settled.
- dubstar-04
- Posts: 698
- Joined: Mon Mar 04, 2013 8:41 pm
- Location: Chester, UK
- Contact:
Re: climb / conventional
Would you mind recording this in mantis then it doesn't get forgotten?
- dubstar-04
- Posts: 698
- Joined: Mon Mar 04, 2013 8:41 pm
- Location: Chester, UK
- Contact:
Re: climb / conventional #4111
Excellent Thanks
Re: climb / conventional
For clarification purposes only, 3D Surface is currently the ONLY operation based on OCL.
The 3D Pocket tool (and others) makes use of the libarea library(I think). Libarea has some long-standing inconsistencies in path generation within various patterns available for selection. However, in its current state, even with the inconsistencies, it is very usable for production - one just has to learn its quarks and behaviors and plan paths and operations accordingly.
Russell
Thanks for you contributions, @freman.
Last edited by Russ4262 on Fri Mar 13, 2020 12:03 am, edited 2 times in total.
Re: Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)
Thanks for the correction, Russ. I was arbitrarily assuming the both the 3D tools used the same libs.
Do you know whether "upstream" are responsive or not? If not maybe there is way to trick OCL to give consistent path direction or filter the returned paths.
Doing two path solutions with a slight offset and then filtering on tool direction could do it. For the path I did here I think I could hack it in awk and stitch the two back together. Maybe this would be too complicated to generalise.
Rather silly actually, OCL is open and could be changed directly.
Do you know whether "upstream" are responsive or not? If not maybe there is way to trick OCL to give consistent path direction or filter the returned paths.
Doing two path solutions with a slight offset and then filtering on tool direction could do it. For the path I did here I think I could hack it in awk and stitch the two back together. Maybe this would be too complicated to generalise.
Rather silly actually, OCL is open and could be changed directly.
Re: Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)
@freman,
OCL is passed line segments from the python script. For the greatest part, path directions in 3D Surface are controlled on the python side through the format in which line segments are created and passed to OCL. So, efforts to maintain climb/conventional path directions require structural changes in the python code for each pattern designed to adhere to climb/conventional directions.
I believe @sliptonic initiated the tool. I'm responsible for the current 0.19 version with multi-pass and rotation. For that reason, I am familiar with the tool and the code structure and many of its limitations, deficiencies, and requested improvements. If you're coding, please feel free to add to and improve the tool. Users would be grateful for additional improvements and bug fixes.
When I get back into FreeCAD mode I hope to pay 3D Surface some "more love", using @sliptonic's words. Limiting it to selected faces is a big request and would be a great improvement for production purposes. Variety in, and adhereance to, specific patterns would also be high on the request list.
Thanks, @freman
Russell
OCL is passed line segments from the python script. For the greatest part, path directions in 3D Surface are controlled on the python side through the format in which line segments are created and passed to OCL. So, efforts to maintain climb/conventional path directions require structural changes in the python code for each pattern designed to adhere to climb/conventional directions.
I believe @sliptonic initiated the tool. I'm responsible for the current 0.19 version with multi-pass and rotation. For that reason, I am familiar with the tool and the code structure and many of its limitations, deficiencies, and requested improvements. If you're coding, please feel free to add to and improve the tool. Users would be grateful for additional improvements and bug fixes.
When I get back into FreeCAD mode I hope to pay 3D Surface some "more love", using @sliptonic's words. Limiting it to selected faces is a big request and would be a great improvement for production purposes. Variety in, and adhereance to, specific patterns would also be high on the request list.
Thanks, @freman
Russell
Last edited by Russ4262 on Thu Sep 05, 2019 3:06 pm, edited 1 time in total.
-
- Posts: 991
- Joined: Wed Mar 27, 2019 10:45 am
Re: Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)
The great Russ on a well deserved break. Hope you're doing okay, Sir. Thank you for the answers.
@freman, "upstream" OCL is owned by Anders Wallin (aewallin) who initiated OCL and OpenVoronoi (the algorithm that Sliptonic is currently experimenting with for V-engraving). He's got a really cool blog.
I am not sure whether he is still pushing the project.
http://www.anderswallin.net/2011/10/ope ... h-freecad/
Edit: at least there seems to be activity on his git on the topic https://github.com/aewallin/opencamlib/issues/76
@freman, "upstream" OCL is owned by Anders Wallin (aewallin) who initiated OCL and OpenVoronoi (the algorithm that Sliptonic is currently experimenting with for V-engraving). He's got a really cool blog.
I am not sure whether he is still pushing the project.
http://www.anderswallin.net/2011/10/ope ... h-freecad/
Edit: at least there seems to be activity on his git on the topic https://github.com/aewallin/opencamlib/issues/76