Slow & incomplete 3D-milling - bug in surface 3d-mill component?

[Siemenc]

I get slow and incomplete 3D-milling toolpaths when calculating a fairly simple surface.

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.

[Siemenc]

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.

[JensDyvik]

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

[Siemenc]

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.

[JensDyvik]

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:

• Stepover distance is much more consistent, no more need to rebuild curves in some circumstances. The stepover is now based on dividing a sample isoccurve of a 90 deg direction in fixed lengths. The sampled isocurve is the longest of out 20 (adjustable inside cluster).
• I added the option to disable collision checking (this makes 3D milling calculation at least 10 times faster, but at the cost of risking to mill away too much material at corners and overhangs). The option is in the bottom of "3D roughing settings", but also impacts 3D finishing.
• Toolpaths are now more reliable in starting at the highest point.
• Weaving seams are a little tidier thanks to better sample point making for collision detection
• For roughing I turned off "Include surface edges" as default. This was seldom needed, but created messy and confusing toolpaths (the option was added in order to reduce the risk of roughing pass leaving too much stock behind).

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

[Siemenc]

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?

[JensDyvik]

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?