Adaptive Path/CAM Operation

Here's the place for discussion related to CAM/CNC and the development of the Path module.
RatonLaveur
Posts: 303
Joined: Wed Mar 27, 2019 10:45 am

Re: Adaptive Path/CAM Operation

Postby RatonLaveur » Thu Sep 05, 2019 1:00 pm

Hello to all,

I've been testing the use of adaptive milling with our laser (how fun!) and have hit a few road-bumps regarding specifically the accuracy of the adaptive.

Considering a tool of 0.1 mm diameter, we have found some "anomalous" behavior of adaptive that actually shows during the machining.

The problem occurs on both my machine
OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16093 (Git)
Build type: Release
Branch: releases/FreeCAD-0-18
Hash: 690774c0effe4fd7b8d2b5e2fb2b8c8d145e21ce
Python version: 2.7.14
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.2.0
Locale: French/Switzerland (fr_CH)

and that of a colleague who uses the most up to date Py3.6/Qt5 v.0.18.3 windows x64 on the freecad frontpage.

Attached you'll find a test model
Adaptive_Milling_Test.FCStd
(22.71 KiB) Downloaded 4 times
where i've removed the adaptive path for size considerations.

You'll find an overview of the test here
2019-09-05_14h45_40.png
2019-09-05_14h45_40.png (92.54 KiB) Viewed 185 times

Typical issues we encounter:

1. The general density of the adaptive path is not uniform, as evidenced by the square area and few denser/less dense areas in the branch progression
2019-09-05_13h56_37.png
2019-09-05_13h56_37.png (183.91 KiB) Viewed 185 times
2. The result can vary from one recompute to the other, but we see some artifacts that are generally more visible after the transition from generation (blue path) to g-code (green path). Hereafter two recomputes show both the presence and the absence of a defect. But random irregularities are always there.
2019-09-05_13h54_15.png
2019-09-05_13h54_15.png (215.28 KiB) Viewed 185 times
2019-09-05_13h54_55.png
2019-09-05_13h54_55.png (224.59 KiB) Viewed 185 times
To note: both our computers use the most accurate (0.001 mm) parameters in the Edit-Parameters-Path tab.

The path defects we mention are not merely artifacts of display, as our laser milling experiments actually shows them on the surface.

Anyone think they have an explanation? or help to offer ?

Thanks a lot!

J.
dubstar-04
Posts: 379
Joined: Mon Mar 04, 2013 8:41 pm
Location: Manchester, UK
Contact:

Re: Adaptive Path/CAM Operation

Postby dubstar-04 » Thu Sep 05, 2019 1:36 pm

In the images that you show the 'less dense' areas seem to be where there are no rapid moves (rapid moves are the red bits).

To confirm this if you change the tool size or the keep tool down setting these lines will change. Reducing the tool size shows the rapid path more clearly:
adaptive.png
adaptive.png (97.85 KiB) Viewed 171 times


These rapid / linking moves are where the tool moves to the start of the next cut. Adaptive tool paths are designed to keep consistent tool engagement for milling operations, if your Laser is on while rapid moves happen then the resulting finish will reflect these moves.

Adaptive clearing tool paths aren't really suited to laser cutters as the intent is to keep tool engagement consistent throughout the clearing / roughing and prevent tool breakage, plus the linking moves are irrelevant on a laser. If your after achieving a better finish you may be better using a finishing op where the laser can remain on and make better use of the lasers time.
Last edited by dubstar-04 on Fri Sep 06, 2019 3:10 pm, edited 9 times in total.
RatonLaveur
Posts: 303
Joined: Wed Mar 27, 2019 10:45 am

Re: Adaptive Path/CAM Operation

Postby RatonLaveur » Thu Sep 05, 2019 1:48 pm

hey dubstar, thanks for chiming in,

I respectfully disagree with three of your three statements ;) :

1. Laser ON during rapids: we have an ultra fast laser, and our post pro is definitely letting the machine rapid with laser OFF.

2. I'm not using a laser cutter but a 6 axis laser machine that behaves very much like a milling tool. Trust me on this one, I know what I'm doing. The main interest of adaptive for my application IS that it keeps engagement constant (when performing laser milling engagement is super important just like conventional milling).

3. The rapids give a wrong overview of the adaptive path density. On that you are quite correct, but rapids fooled you in this case (or my screencap skills are terrible, which is equally possible). Exhibit A:
2019-09-05_13h51_59.png
2019-09-05_13h51_59.png (126.98 KiB) Viewed 167 times
I managed to screencap the generation of the path, and you can see the "square" is very much there. As are a few artifacts to the right.

Did I adequately convince you that my question may be well founded?
kreso-t
Posts: 114
Joined: Sat Aug 04, 2018 2:32 pm

Re: Adaptive Path/CAM Operation

Postby kreso-t » Thu Sep 05, 2019 6:24 pm

RatonLaveur wrote:
Thu Sep 05, 2019 1:00 pm
Hello to all,

I've been testing the use of adaptive milling with our laser (how fun!) and have hit a few road-bumps regarding specifically the accuracy of the adaptive.

Considering a tool of 0.1 mm diameter, we have found some "anomalous" behavior of adaptive that actually shows during the machining.

The problem occurs on both my machine
OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16093 (Git)
Build type: Release
Branch: releases/FreeCAD-0-18
Hash: 690774c0effe4fd7b8d2b5e2fb2b8c8d145e21ce
Python version: 2.7.14
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.2.0
Locale: French/Switzerland (fr_CH)

and that of a colleague who uses the most up to date Py3.6/Qt5 v.0.18.3 windows x64 on the freecad frontpage.

Attached you'll find a test model Adaptive_Milling_Test.FCStd where i've removed the adaptive path for size considerations.

You'll find an overview of the test here 2019-09-05_14h45_40.png


Typical issues we encounter:

1. The general density of the adaptive path is not uniform, as evidenced by the square area and few denser/less dense areas in the branch progression 2019-09-05_13h56_37.png

2. The result can vary from one recompute to the other, but we see some artifacts that are generally more visible after the transition from generation (blue path) to g-code (green path). Hereafter two recomputes show both the presence and the absence of a defect. But random irregularities are always there.2019-09-05_13h54_15.png2019-09-05_13h54_55.png

To note: both our computers use the most accurate (0.001 mm) parameters in the Edit-Parameters-Path tab.

The path defects we mention are not merely artifacts of display, as our laser milling experiments actually shows them on the surface.

Anyone think they have an explanation? or help to offer ?

Thanks a lot!

J.
Hi,

Adaptive alg. is not tuned to work with such small tool diameter with such precision that you require.
There are number of parameters within the alg. that would need to be adjusted for alg. to work precise enough under these conditions.
But adjusting the parameters in this way would have negative impact on overall performance when used with larger tools.
These parameters could be made dependent on the tool diameter - so that one set of parameters are used for larger tools and second set for very small tools. That would require additional development/enhancements withing the alg.

Maybe you could get desired result if you scale up the model i.e. 100 times (with tool diameter also scaled 0.1 mm -> 10 mm ), calculate the adaptive tool paths with such scaled model and tool and then in the post-processor scale them back down 100 times (by customizing the post-processor code)?

BR,
K.
RatonLaveur
Posts: 303
Joined: Wed Mar 27, 2019 10:45 am

Re: Adaptive Path/CAM Operation

Postby RatonLaveur » Thu Sep 05, 2019 6:35 pm

Yes i was certain it was something like that.
You say the algo is using some accuracy parameters that are balanced to not over burden with calculation. I get that.

What I'm puzzled about is why you estimate that making such parameters dependant on tool diameter would be a significant development? Alternatively could a "stupid accurate" version of the algo be mustered?

Here I'm only showing my lack of code understanding and diving deep in the Dunning-Kruger curve...so please bear with my ignorance :)

Another thing I'm curious about is that it seems the generation of the blue wires is always more accurate than the resulting G-code. Although, as evidenced, some areas can be less "dense" (the elbow's main square) which does translate in slightly less depth when laser milling.

To note: my first tests using this adaptive with very minor adaptation to accommodate our non-conventional tool were so pleasing that I cannot but ask how to tweak the algo to suit these needs :) there's a certain simple elegance in using a brute milling algorithm with a beautiful ultra high accuracy beam...
kreso-t
Posts: 114
Joined: Sat Aug 04, 2018 2:32 pm

Re: Adaptive Path/CAM Operation

Postby kreso-t » Thu Sep 05, 2019 7:06 pm

RatonLaveur wrote:
Thu Sep 05, 2019 6:35 pm

What I'm puzzled about is why you estimate that making such parameters dependant on tool diameter would be a significant development? Alternatively could a "stupid accurate" version of the algo be mustered?
Finding the optimal values is actually the difficult part. Originally it took weeks to optimize the parameters so that alg. is fast enough, precise enough and stable. "Stupid accurate" version would take hours to calculate paths even for simple models, and the output number of points (and hence g-code file size) would be enormous. Also ATM other obligations do not leave me much free time to have fun with this. I'll try to look at it when I get some free time.
RatonLaveur
Posts: 303
Joined: Wed Mar 27, 2019 10:45 am

Re: Adaptive Path/CAM Operation

Postby RatonLaveur » Thu Sep 05, 2019 7:14 pm

Thanks for the clarification. Much appreciated.

We wouldn't want a 1Gb G-code file after 10hrs of computing now would we ;)
chrisb
Posts: 17515
Joined: Tue Mar 17, 2015 9:14 am

Re: Adaptive Path/CAM Operation

Postby chrisb » Thu Sep 05, 2019 10:01 pm

RatonLaveur wrote:
Thu Sep 05, 2019 7:14 pm
We wouldn't want a 1Gb G-code file after 10hrs of computing now would we ;)
No, we wouldn't. Not with 20K of memory:
Attachments
screenshotVersion.jpg
screenshotVersion.jpg (89.88 KiB) Viewed 96 times
RatonLaveur
Posts: 303
Joined: Wed Mar 27, 2019 10:45 am

Re: Adaptive Path/CAM Operation

Postby RatonLaveur » Fri Sep 06, 2019 7:54 am

Awesome. Thanks for the chuckle.

One point of my original query may not have been extra clear:

It seems that the blue generative path is already much more accurate than the resulting G-Code path. Perhaps there's something to be done here?
dubstar-04
Posts: 379
Joined: Mon Mar 04, 2013 8:41 pm
Location: Manchester, UK
Contact:

Re: Adaptive Path/CAM Operation

Postby dubstar-04 » Fri Sep 06, 2019 3:15 pm

RatonLaveur wrote:
Thu Sep 05, 2019 1:48 pm

2. I'm not using a laser cutter but a 6 axis laser machine that behaves very much like a milling tool. Trust me on this one, I know what I'm doing. The main interest of adaptive for my application IS that it keeps engagement constant (when performing laser milling engagement is super important just like conventional milling).
It seems I misunderstood the images. :oops:

What are the benefits of using adaptive strategies with your laser process?

Do you have any information about the machine? Its not something I have used before.

Thanks,

Dan