Last Minute Roughing Change

on Wed, Jul 01, 2009 in development

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.

image

image

image

Recent Posts