I am cutting out a box to hold my new Bridge City tools. The first pocket left a big hump but went back and cut the hump out before moving to the next pocket. It worked but I have never seen this behavior before
1 Like
This looks like the same problem as this:
In short, some pockets are being cut DEPTH first instead of BREADTH first. It’s a serious bug, but there’s no ETA for a fix.
1 Like
I’ve seen the same issue with cutting letters. Example it will cut the outline of the letter O or D then after all the letters are outlned it will go back and cut out the center of the O or the D. Also when cutting a word like “Name” it will cut the N then the e, then the a then the m. Not a big deal but seems like CC makes its own decision on what order to cut things. When that occurs i keep thinking i missed something on the tool path, but eventually it finishes the cut.
CC is not alone in that process. Many times I sit and wonder at the “optimization” that Vectric Vcarve Pro uses to cut parts.
1 Like
This is an “NP-Hard” problem in computer science known as “The Traveling Salesman” — it’s not possible to have a single algorithm to always calculate an optimal path which runs more quickly than trying all the possibilities (which takes a very long time even on a modern computer).
2 Likes
What I find frustrating about the algorithms is how they do not take into account time wasted on retract/move to different features - every move to a new feature results in a time penalty.
Overall it would be faster to keep the bit down & completing a ‘feature’ until full depth & detail reached before retract/move to next feature - it would be nice to have a way to number features in a design to tell the algorithm what you want it to cut first(I realize this can already be achieved to a degree in CC by manually creating/ordering tool paths - but I like to dream) . Also, minimizing the number of retracts within cutting a feature.
But I can appreciate that turning my ‘progression’ rules into an algorithm that functions properly for all/most design context is no easy feat.
1 Like
You should be able to achieve what you describe by selecting fewer pieces of geometry and creating toolpaths as needed to cut thus.
1 Like
While some of the scenarios people have mentioned in this thread can be solved by selecting less geometry, I don’t think that applies to the OP’s original issue.
It looks like he is doing a pocket operation, but it is being processed and cut like a contour path. This seems more like a bug than a “hard computer science” problem.
Having said all that, I don’t feel like I need to create 4 separate tool paths just so the word ‘Name’ will be carved in the logical (English) order.
This topic was automatically closed after 30 days. New replies are no longer allowed.