Open Siemenc opened 5 years ago
My assumptions were correct, I think. I went for the same surface and same settings from this:
To this:
And this toolpath output:
I'll be doing quite some 3D-milling in the coming weeks so I'll get to crash test this and see if any other bugs pop up by fixing this.
This is great bug to iron out. Thank you! I can not remember having problems with simple surfaces before. But lately I have had many data tree problems in rhino6 in definitions made in GH in rhino5 (especially 3D milling from meshes and tabs on 3D objects). Maybe some ways of handling data trees and paths have changed in new GH?
Also important, we need to find a better way to publish the latest version of a complete bark beetle definition (or example of use of components). For now, could you update this file with your fixes? https://github.com/fellesverkstedet/Bark-beetle-parametric-toolpaths/tree/master/Examples%20-%20Stable%20release
My findings might have been based upon a previous version. When I opened the last Rhino6 file and tried getting the same issue I couldn't repeat the behavior. Will do some more testing before fixing and committing.
I have been making some improvements to 3D milling in "Bark beetle 1.02 beta 5 - CNC milling - Rhino6.gh" published here: https://github.com/fellesverkstedet/Bark-beetle-parametric-toolpaths/tree/master/Development%20files
The improvements are:
Testing and feedback is very welcome and appreciated!
Distrubtion of isocurve based toolpaths the old way
_Distrubtion of isocurve based toolpaths with the new approach
Example of corners getting milled into with "Collsion detection" turned off
With "Collision detection" on everything is nice and clean, but takes about 10 times longer to calculate
Nice progress, looks good! Do I get it correct that if you have single face surfaces without undercuts, you can always leave collision detection turned off without having to worry?
Also, just to be sure: In the current beta versions: are they a continuation of each other or does each different beta version contain an improved part which would need to be combined before becoming a new version?
Yes, in most single surface 3D milling scenarios it would be safe to leave collision detection off. The exemption would be a curving surface having a quite sharp internal corner (radius of corner smaller than radius of the milling bit) or overhangs like you mention. All flat single surfaces should be very safe to calculate without collision detection.
The betas are a continuation off eachother. Otherwise I think it would be too much work to merge different development (since there is no git merge/diff support for GH files). So I am thinking if one of us introduces a new bug in a beta, we can copy and paste a better solution from an older file. I think we should all try to do new work in (or paste into) the latest beta file for best collaboration. What do you think?
I get slow and incomplete 3D-milling toolpaths when calculating a fairly simple surface.
![image](https://user-images.githubusercontent.com/10272127/61635117-1f7d8300-ac93-11e9-8566-6e845a938417.png)
When investigating I think it might have something to do with the difference in tree branches inside the surface 3D mill component. Looking further into this.![image](https://user-images.githubusercontent.com/10272127/61635319-987cda80-ac93-11e9-8ce4-f036c085a4ff.png)