Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
freman
Veteran
Posts: 2198
Joined: Tue Nov 27, 2018 10:30 pm

Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)

Post by freman »

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.
Attachments
3Dsurface-detail.jpeg
3Dsurface-detail.jpeg (443.97 KiB) Viewed 2190 times
Last edited by Kunda1 on Mon Sep 02, 2019 4:51 pm, edited 2 times in total.
Reason: Updated thread title
mlampert
Veteran
Posts: 1772
Joined: Fri Sep 16, 2016 9:28 pm

Re: climb / conventional

Post by mlampert »

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.
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.

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.
User avatar
freman
Veteran
Posts: 2198
Joined: Tue Nov 27, 2018 10:30 pm

Re: climb / conventional

Post by freman »

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.
User avatar
dubstar-04
Posts: 698
Joined: Mon Mar 04, 2013 8:41 pm
Location: Chester, UK
Contact:

Re: climb / conventional

Post by dubstar-04 »

Would you mind recording this in mantis then it doesn't get forgotten?
User avatar
freman
Veteran
Posts: 2198
Joined: Tue Nov 27, 2018 10:30 pm

Re: climb / conventional #4111

Post by freman »

User avatar
dubstar-04
Posts: 698
Joined: Mon Mar 04, 2013 8:41 pm
Location: Chester, UK
Contact:

Re: climb / conventional #4111

Post by dubstar-04 »

Excellent Thanks
Russ4262
Posts: 941
Joined: Sat Jun 30, 2018 3:22 pm
Location: Oklahoma
Contact:

Re: climb / conventional

Post by Russ4262 »

freman wrote: Mon Sep 02, 2019 6:10 am...I knew that 3D tools were using OCL...

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.
User avatar
freman
Veteran
Posts: 2198
Joined: Tue Nov 27, 2018 10:30 pm

Re: Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)

Post by freman »

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.
Russ4262
Posts: 941
Joined: Sat Jun 30, 2018 3:22 pm
Location: Oklahoma
Contact:

Re: Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)

Post by Russ4262 »

@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
Last edited by Russ4262 on Thu Sep 05, 2019 3:06 pm, edited 1 time in total.
RatonLaveur
Posts: 991
Joined: Wed Mar 27, 2019 10:45 am

Re: Ticket #4111 - climb / conventional (inconsistent cut direction in 3Dsurface)

Post by RatonLaveur »

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
Post Reply