ADD: A new waterline algorithm
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
ADD: A new waterline algorithm
A new waterline algorithm "grid dropcutter" was developed. This algorithm was inspired by ideas of OCL Dropcutter, but is about 10 times faster and doesn't use OCL library. Instead the hard calculations are performed with numpy library. For rectangular mill the complexity is about 2.45 power of resolution. I will prepare the pull request soon.
In screenshot: the processed area is 50 x 25 mm, sampling interval 50um, processor AMD FX-8370. Dropcut scans are 5.6 .. 2.3 s, total time is 24.5 s.
In screenshot: the processed area is 50 x 25 mm, sampling interval 50um, processor AMD FX-8370. Dropcut scans are 5.6 .. 2.3 s, total time is 24.5 s.
- Attachments
-
- Screenshot_20220127_091801.png (266.32 KiB) Viewed 2914 times
Re: ADD: A new waterline algorithm
What a great news!
Thx for your effort
Thx for your effort
Re: ADD: A new waterline algorithm
+1
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: ADD: A new waterline algorithm
Interesting! Is your code online somewhere?
Re: ADD: A new waterline algorithm
Look at the branch
https://github.com/belov-oleg/FreeCAD/t ... dropcutter
Two filles (PathWaterlineGui.py and PathWaterline.py) should be changed and one new file (PathLevelMap.py) should be appended. No recompilation required.
https://github.com/belov-oleg/FreeCAD/t ... dropcutter
Two filles (PathWaterlineGui.py and PathWaterline.py) should be changed and one new file (PathLevelMap.py) should be appended. No recompilation required.
-
- Posts: 541
- Joined: Fri Aug 26, 2016 9:07 pm
- Location: Munich - Gemany
Re: ADD: A new waterline algorithm
Very promising.
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: ADD: A new waterline algorithm
Hi obelov,
Could you give a high-level explanation of how the algorithm works? Also if you have a working example and/or screenshots of the resulting path, that would be helpful.
I'd also like to talk about integrating this into Path differently. I want to get the actual toolpath generation stuff out of the operations and into generators.
BTW, thanks for writing unit tests!
Could you give a high-level explanation of how the algorithm works? Also if you have a working example and/or screenshots of the resulting path, that would be helpful.
I'd also like to talk about integrating this into Path differently. I want to get the actual toolpath generation stuff out of the operations and into generators.
BTW, thanks for writing unit tests!
Re: ADD: A new waterline algorithm
Awesome @obelov
Looking forward to seeing your work in FreeCAD
Looking forward to seeing your work in FreeCAD
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: ADD: A new waterline algorithm
Thanks for acclamation .
I will prepare the description soon. Just now I pushed to my branch the version with one fixed bug and a serious improvements in performance for high resolutions. Now I can process my model of size 25x50 mm with resolution 10um in 133s only. This version works but is lacking in some settings.
It sounds very promising to integrate this algorithm or any similar one into other instruments. I'm using Path for my first CNC project, and I'm disappointed by non-uniformity of operations. IMHO all operations, even declared as 2D, should avoid cutting any extra pieces of the entire model (not only the selected set of features) which can be touched by the mill, an should gracefully jump over raised parts without explicit declaration. On the other hand the possibility to switch off some features from this control can be necessary for final cut-off.
Also for my job will be very pleasant to have 4-axis profiling of a curved surface so as to keep rectangular mill always normal to the surface.
I'm ready for cooperation.
I will prepare the description soon. Just now I pushed to my branch the version with one fixed bug and a serious improvements in performance for high resolutions. Now I can process my model of size 25x50 mm with resolution 10um in 133s only. This version works but is lacking in some settings.
It sounds very promising to integrate this algorithm or any similar one into other instruments. I'm using Path for my first CNC project, and I'm disappointed by non-uniformity of operations. IMHO all operations, even declared as 2D, should avoid cutting any extra pieces of the entire model (not only the selected set of features) which can be touched by the mill, an should gracefully jump over raised parts without explicit declaration. On the other hand the possibility to switch off some features from this control can be necessary for final cut-off.
Also for my job will be very pleasant to have 4-axis profiling of a curved surface so as to keep rectangular mill always normal to the surface.
I'm ready for cooperation.
New algorithm and the idea of generators
I studied the code in the branch about scripting. The idea of generators is IMHO very good and important, but I'm not in agree with the proposed in/out specifications. Generators should support chaining. For example one generator should analyze the job and generate the outer contour of the pocket, the next generator in the chain can produce the pattern, for example zigzag, for processing of the bottom, the next one can add small rotation around A-axis to produce fine curved surface with endmill and the last one can verify (and correct) path for probably conflicts with stock holders.
All generators can extract data from model immediately or through helpers.
operation->gen1->gen2->..->genN->GCode_generator
| | |
| | helper
model
In this case the data transferred between generators can be expressed as a list of N-dimensional points, probably flavored. FreeCAD points have only 3 dimensions, and usage of G-code in form of either string or tuple IMHO can decrease the speed of processing. I would prefer a simple tuple of coordinates with optional named tuple of flavors in the last element. A flavor can mark the preferred interpolation in given node with circle, decreased velocity or something more.
All generators can extract data from model immediately or through helpers.
operation->gen1->gen2->..->genN->GCode_generator
| | |
| | helper
model
In this case the data transferred between generators can be expressed as a list of N-dimensional points, probably flavored. FreeCAD points have only 3 dimensions, and usage of G-code in form of either string or tuple IMHO can decrease the speed of processing. I would prefer a simple tuple of coordinates with optional named tuple of flavors in the last element. A flavor can mark the preferred interpolation in given node with circle, decreased velocity or something more.