search

fellesverkstedet / Bark-beetle-parametric-toolpaths

A grasshopper plugin for digital fabrication. Enables direct fabrication of geometry with 3D printers, CNC milling, Laser cutters, Robot arms and more. Also featuring 1:1 augmented reality toolpath projections.
100 stars 18 forks source link

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

Open Siemenc opened 5 years ago

Siemenc commented 5 years ago

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

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

Siemenc commented 5 years ago

My assumptions were correct, I think. I went for the same surface and same settings from this: image image

To this: image image

And this toolpath output: image

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 commented 5 years ago

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 commented 5 years ago

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 commented 3 years ago

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!

old isocurve dist Distrubtion of isocurve based toolpaths the old way

new isocurve dist _Distrubtion of isocurve based toolpaths with the new approach

example no collsion detection Example of corners getting milled into with "Collsion detection" turned off

example with collsion detection With "Collision detection" on everything is nice and clean, but takes about 10 times longer to calculate

Siemenc commented 3 years ago

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 commented 3 years ago

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?