Adaptive Path/CAM Operation

[chrisb]

I couldn't test it yet (currently only on MacOS) but the images look very promising.

[kreso-t]

The only thing is that FreeCAD does not include the pyclipper module by default so it requires additional installation (it's acctually a very small library in terms of footprint) , maybe Path.Area could be extended to provide access to lower level clipper operations (and perhaps some other low level 2d geometry operations - like finding instersection points of path and line segment, etc.) then dependency to pyclipper would not be needed.

The path shown in the screenshot is so nice! Great work!

Just name the API you want, maybe a little document. I'll add it to Path.Area.

Thx, I use most of the methods/API pyclipper provides (except for Minkowsky sum/diff stuff) so maybe it would be the most convenient to reuse the pyclipper source and map it to i.e. Path.Area.ClipperLib "namespace".

Did you try to run it - what do you think about the performance, does it look acceptable ( I am a little biased there:) )?
(if it does not look acceptable we should probably look at the other solution - porting the core part to C/C++))

BR,
K.

[roivai]

I tried it quickly - worked great! I think the performance was OK'ish.. I'm not sure how, but initially, the algorithm took quite a while to run, it visualized all the steps on screen and then produced the final path. But then when I changed some settings, the path also updated "on the fly" with no visible delay at all, so is it so that the algorithm initially takes longer or is there some visualization aspect you are doing intentionally?

One nice addition (or maybe another operation using the same algo) would be cutting profiles around a shape with trochoidal machining. Like I suggested in another thread. That would probably be as simple as generating two offset paths from the shape and applying this algo on the area between them.

[kreso-t]

I tried it quickly - worked great! I think the performance was OK'ish.. I'm not sure how, but initially, the algorithm took quite a while to run, it visualized all the steps on screen and then produced the final path. But then when I changed some settings, the path also updated "on the fly" with no visible delay at all, so is it so that the algorithm initially takes longer or is there some visualization aspect you are doing intentionally?

This part that runs initially (when there is the visualization shown) is acctually when it calculates the adaptive path. If you after that change some settings related to Z axis that is not affecting the adaptive path (i.e. like depths, heights, step down or helix ramp angle...) it will reuse the same previously calculated paths and just apply them to different depths, so in this case it updates the final toolpath almost instantly. If you change step over or tool diameter, ... or other setting that influences the path in XY plane then it will again go trough full recalculation.

...
One nice addition (or maybe another operation using the same algo) would be cutting profiles around a shape with trochoidal machining. Like I suggested in another thread. That would probably be as simple as generating two offset paths from the shape and applying this algo on the area between them.

yes, I think this shouldn't be a problem to do, it should work in the way you proposed.

However I am still not at peace with the performance aspect of the alg. , I plan to do a test implementation in C++ of that one critical part (that is clipping the toolshape against the cleared region and calculting the area the tool crosses outside - which takes majority of the time because it's relatively complex part and repeated many times) to see how much faster could that potentially be if ported to C++ compared to python. Also I currently use polygon clipping for this which might not be the optimal solution, having in mind that tool shape is circular so basically can be described by one point and radius instead of circular shaped polygon ... just need to figure out how to efficiently calculate area of circle splited by an arbitrary path - but I think it should be possible to make it faster than using general polygon clipping...

BR,
K.

[realthunder]

Thx, I use most of the methods/API pyclipper provides (except for Minkowsky sum/diff stuff) so maybe it would be the most convenient to reuse the pyclipper source and map it to i.e. Path.Area.ClipperLib "namespace".

Did you try to run it - what do you think about the performance, does it look acceptable ( I am a little biased there:) )?
(if it does not look acceptable we should probably look at the other solution - porting the core part to C/C++))

BR,
K.

In that case, yeah, we can just grab pycipper's code and complie into FC. I tried it. The speed is acceptable, especially since you show the path while generating it, it gives user a progressive perception.

I plan to do a test implementation in C++ of that one critical part (that is clipping the toolshape against the cleared region and calculting the area the tool crosses outside - which takes majority of the time because it's relatively complex part and repeated many times)

Maybe you can use a few picture to explain this part. Maybe Part.Area or OCCT can already do this.

[kreso-t]

For example, if at some point (step n) we have the following cleared area, tool position + direction:

step1.png (45.55 KiB) Viewed 2331 times

In the next step we try to move the tool by certain small distance (i.e. it is not tool radius as the image may imply, it's smaller variable step) in the direction "deflected" by some angle. And there we need to find the optimal "deflection" angle so that cut area (red part) is equal to desired/optimal cut area initially set via "step over" parameter. This is done through iterations where cut area is first probed/calculated for some initial guessed angle and then in each following iteration previous results are used to better guess next angle until we get close enough to desired area (I think this is a kind of "successive approximation" method, not sure exactly). Basically we are in a way discovering this function "f" at each point as it depends on the exact shape we are cutting. So determinig the area of this red part as efficient as possible is the key to performance of this alg. as this is the most frequent operation. Currently this is done by polygon clipping (i.e. difference between new tool position and old position and then difference to "cleared" area and then calculate the area of resulting polygon). I tried to run this through a profiler (cProfile) and based on the result the most time is lost in the pyhton code and not actually in the clipping part (clipping operations seem to take only about the 10% of the total time) - so it seems that just porting the alg. to the C/C++ as it is would bring significant perfomance improvement.

step2.png (58.65 KiB) Viewed 2331 times

[realthunder]

Thanks for the explanation. I'll see what I can do.

[jbi]

Hi,

How long does it take to calculate such a step and on which processor?

[kreso-t]

Hi,

On my laptop (windows): i7-3610QM CPU @ 2.30GHz

according to cProfile it takes in average ~1.3 ms to calculate one step/point (all iterations), to calculate only one cut area (the red polygon on the second picture) it takes avg. ~0.13 ms

I just tried to do some parts of it in C++, it's like 15 times faster - using practically the same code just in C++ syntax (for example 1 million executions of translatePath function (that is also used quite often) in python take 15 seconds, the same in C++ takes only 0.9 sec) ... so definitely will port the core alg. to C++

BR,
K.

[kreso-t]

Just finished porting the core algorithm to C++. You may check it out at https://github.com/kreso-t/FreeCAD_Mod_ ... e_Path-Cpp

Works a lot faster now and does not have dependency to pyclipper anymore (uses clipper.hpp/clipper.cpp - same as Path.Area)

The core part is implemented as one hpp + cpp file (adaptive.hpp + adaptive.cpp) and only python bindings are separate (bindings.cpp, currently using pybind11). It provides one main public class (currently named PathAdaptiveCore.Adaptive2d) for generating the 2d adaptive toolpaths based on provided input 2d paths/shapes and given settings (such as tool diameter, step over percent, etc. ...set as member variables of that class). The python code uses that class to generate paths in XY plane and from its results (return value of method Adaptive2d.Execute) generates final gcode (adding Z axis).

One nice addition (or maybe another operation using the same algo) would be cutting profiles around a shape with trochoidal machining. Like I suggested in another thread. That would probably be as simple as generating two offset paths from the shape and applying this algo on the area between them.

Based on roivai idea this version also supports the profiling mode (see attached image) in addition to adaptive clearing option.

This version also uses a different way of calculating the "cut area", it is no longer treating the tool as polygon, instead the tool is described with one vector (center point) and scalar (radius) and algorithm works with that to find the cut area (against the "cleared" region that is still treated as polygon) , so it does a lot less polygon clipping and it is also faster for that reason.

The code probably still needs some polishing and fine-tuning but it seem to work ok for now.