Last Minute Roughing Change
I had a terrifying thing happen yesterday. I was testing the new roughing code and I found a bug in the offset code that generated a hard crash; unfortunately it was in a small piece of code that I licensed and is poorly documented. I think it was due to a piece of my code giving it a bad geometry outline but that doesn’t change the fact that it generated a hard crash that I couldn’t recover from or detect before it happened.
Out of fear of future trouble I decided to change to my parallel pocket code that’s used in the parallel finishing toolpath. This also choked on the bad data but only gave me a bad toolpath instead of a crash. While not good this is always preferable to a crash. The parallel code also helped me find the flaw in my code that generated the bad outline.
The good thing is that the parallel code is much faster- up to about 10 times faster. So here’s where I stand: I am always afraid of offset pocket algorithms and they’re relatively slow but I’ve invested a lot of time in this one and it has never failed when given good data…. and pride won’t let me drop it. The contour offset and parallel algorithms are almost drop-in compatible so I’m going to include both and let the user pick which one. Both will support the “3D Roughing” previously referred to as “Contour Roughing.”
I also fixed the bad vertical spikes. The paths look very nice now.
Comments
5 Responses to “Last Minute Roughing Change”
Robert, that’s looking fantastic! What’s the pathlength of the parallel vs. offset roughing? As neat as the offset path looks, there are a whole lot of retracts involved–it looks like the parallel keeps the cutter down in the material more consistently.
If I were to make a small UI suggestion, it would be to make “Roughing Style” offset/parallel radio buttons like the “Mill Direction” climb/conventional.
And if I’m not mistaken, I think the former name was “Conformal Roughing”–in any case, I’ll quietly give up my career ambition of algorithm naming… I like “3D roughing”.
Randy
The first pic appears to be back and forth parallel. How does climb or conventional fit in there? Looks like both? When cutting wood, the back and forth can result in a lot of tearout, so direction is important.
Gerry
Randy- I haven’t looked at the pathlength but I did read a paper some time ago that indicated, if I remember correctly, that parallel paths were better for thinner/longer pockets and contour offset was better for square/circular. It would be interesting to look at this when I get the machine time estimation code done.
There are some extra retracts in the contour code that will have to be fixed.
Gerry- Good catch. I’ll have to gray-out the direction when using parallel paths. Contour will give better tearout conrtol for wood machining.
Any chance of having a parallel roughing option that does do climb or conventional? The old standard cut, lift, return, repeat method?
I guess it could be possible in the long-term but the pocket code I’m using is the same one from the finishing so it only supports generating a fully-connected toolpath.
The old ZMap code that allowed the cut-and-lift is not compatible with the new roughing system and has been removed from the project. On the positive side, roughing should be much more accurate and smooth now.