Adaptive Path/CAM Operation

[kreso-t]

I submitted the PR to FreeCAD master. The adaptive operation is added as experimental feature.
As this is my first ever Pull Request using GitHub , pls. let me know if I should do something differently (I can cancel/close it and make a new one).

I looked at your PR and as expected you did a great job. The only recommendation I would have going forward is shooting for more expressive commit messages. It is quite unlikely that your PR gets invalidated since your code is new. But maybe check every now and then if your branch is still up to date, if not pressing the "Update branch" usually does the merge for you. Other than that, address review comments if there are any and once the maintainers are satisfied (and have some time) they will merge the branch and we all get to use your op

Thanks, this is really great!

Ok, thx, will pay more attention to those commit messages. I assumed that PR will not include my whole commit history I made in my forked repo (I kind of expected there will be only one commit message for whole PR). Also the thing with Git seem to be that you cannot change the commit messages retroactively, which was a suprise for me as with SVN, which I mostly use, it is possible to do that. Also I probably need to use more that Git staging feature (which does not exist with SVN) instead of frequent commits (i.e. in case when I still did not finish some feature completely but want to have some intermediate version stored so that I can revert to it if neccessary).

BR,
K.

[mlampert]

Ok, thx, will pay more attention to those commit messages. I assumed that PR will not include my whole commit history I made in my forked repo (I kind of expected there will be only one commit message for whole PR). Also the thing with Git seem to be that you cannot change the commit messages retroactively, which was a suprise for me as with SVN, which I mostly use, it is possible to do that. Also I probably need to use more that Git staging feature (which does not exist with SVN) instead of frequent commits (i.e. in case when I still did not finish some feature completely but want to have some intermediate version stored so that I can revert to it if neccessary).

You can, what you want to look at is "git rebase -i" (for interactive), and then you can "squash" your commits into a single one, pretty much do what you want. I would recommend doing it in a separate branch though until you're familiar with what is going on - you are rewriting history

[dubstar-04]

Adaptive Operation is now in master!

Fantastic achievement!

[kreso-t]

Adaptive Operation is now in master!

Fantastic achievement!

Thx Dan,

What do you think how beneficial would it be to make those lead-in and lead-out moves to be linked more tangentially i.e. connected by arc instead of straight line? I had a plan to add this, but as it is somewhat complex addition I am not sure whether is it worth the effort. My reasoning is that it would not bring much benefit to surface finish (there is already finishing pass at the end and adaptive paths before it are slightly offseted from boundary), but it may be beneficial for smoother machining cause it would lower (to some extent) the neccessary decelerations and accelerations (on my machine I would probably not feel any difference as max possible feedrate is not very high and machine is very light).
Sure toolpaths would visually look nicer (not sure if that is reason enough )

2018-09-12_8-49-46.png (12.26 KiB) Viewed 1395 times

BR,
Kreso

[sliptonic]

Additional features and improvements are always welcome but I'd suggest letting the community hammer on it a bit and focusing on speed improvements. So far, I've only played but a mildly complex pocket can take a VERY LONG time to complete. The issue might be related to the animation but my observations aren't scientific (or even trustworthy). Some kind of actual analysis might be in order.

[kreso-t]

Additional features and improvements are always welcome but I'd suggest letting the community hammer on it a bit and focusing on speed improvements. So far, I've only played but a mildly complex pocket can take a VERY LONG time to complete. The issue might be related to the animation but my observations aren't scientific (or even trustworthy). Some kind of actual analysis might be in order.

A lots of efforts has already been put to performance optimisation i.e. when you compile it with #define DEV_MODE it will dump performance statistics showing which parts of code took the most cumulative time, time per execution and total number executions and that was used as feedback for optimisations ... but sure with these things you can always do better. And for the most recent versions I should probably re-check those performance statistics, maybe there still is some room for improvements. The issue is definetly not related to animation (a few percent at most as animation is decoupled from processing, animation executes at constant rate of ~20 FPS drawing paths incrementally from last GUI refresh). Based on my experience with other CAM software these adaptive toolpaths are also there not calculated instantly (it can take several seconds depending on the model compexity and settings).

I.e. with this model from Dan on my PC takes 2.85 sec to calculate the toolpath on the picture:

2018-09-12_17-04-35.png (152.55 KiB) Viewed 1356 times

I find that quite acceptable. How long did it take with your tests? Can you send me the model and settings you tried with (could it be something specific to your model)? What are your expectations, what would be acceptable time for you?

Further more significant performance enhancements would probably need to go in direction of utilising more CPUs - but this would open the whole another can of worms (concurrency issues, splitting the current linear algorithm into independent parts that can be run in parallel, thread synchronisation with GUI thread, etc.)

[sliptonic]

On my work computer, the model took about 30 seconds. On my home computer (which should be faster) it was about 8 minutes.
I've attached the file for reference.

[kreso-t]

On my work computer, the model took about 30 seconds. On my home computer (which should be faster) it was about 8 minutes.
I've attached the file for reference.

On my linux PC at home with AMD FX6300 this exact file takes about 15 seconds without any modifications in settings
(FX6300 this is relatively old CPU which is not the best choice for single threaded processing - most of lower end Intel I3 and I5 should be much better). Will try tomorrow on my work computer.

8 minutes on a faster PC is definitely too long - must be something going wrong but I don't have a clue what could it be without more information

Also this model is relatively large, it's more than half meter long - a lot of area to cover by the alg. so maybe 15-30 seconds is to be expected here.
With smaller models and default accuracy settings it should work in the range of few seconds.

BR,
K.

[sliptonic]

Agree. If it's completing in less than a minute, I'm happy with a model like this.
I'll post some more details about the home machine tonight.

[sliptonic]

Using the same model at home (AMD FX(tm)-4100 Quad-Core Processor 12GB), I'm seeing this result:

*** Adaptive toolpath processing started...
Tool diam: 6.350000
*** Done. Elapsed: 322.135314 sec

The first 2/3 of the path generate quite fast ~15 seconds. The rest goes very slow. I had htop running and the four CPU cores were bouncing around 17%. Max memory usage for freecad about 30%. System peak memory usage about 6GB of 12GB. Plenty of swap.

I shut down every other application I could and shaved about 10 seconds off the total time.