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
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.
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.
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).
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.
You should be able to achieve what you describe by selecting fewer pieces of geometry and creating toolpaths as needed to cut thus.
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.