GRZ Software Blog

News and tips for MeshCAM

April Update

I mentioned in the last post that I found a bad bug in the parallel roughing and that I had been working on resolving it. At the time I still hadn’t even figured out the cause of the problem but hours of staring at debug data finally showed the conditions that cause it: “Machine geometry + “ set to zero. By now I’ve forgotten why I even used this setting but I used it with a very complicated part that contained check surfaces so it took a long time to understand the problem and the exact conditions that caused it. I thought I understood it last time I posted but I was off by a bunch.

It turns out that the roughing module comes up with a set of pockets and islands to machine as does the “Machine Geometry +” code. If the machining margin is always greater than the tool diameter, as I originally had it, then the pockets will be formed in a way that there are no problems; the machine margin boundary will always be outside the roughing pocket. If, however, the margin is set to zero then you can end up with a case where the two sets of pockets and islands are mutually exclusive- that is, there is no valid area to machine at that point even though you have several pockets and islands. Unfortunately, the current code can’t figure this out so it comes up with unbelievably incorrect toolpaths. I wish I had some photos to show the problem in detail but it’s a really hard thing for me to show clearly.

I’ve written some code to carefully decompose the pockets and islands into very simple areas that can be safely combined with one another. It’s not difficult code but there are a significant number of cases to verify. As of right now my test code is almost equal in length to the actual pocket sorting code. By the time I’m done I think the test code will probably be significantly larger than the actual code.

There are two benefits from this new code- first, I hope the bugs will be fixed. Second, I now have a simple list of pockets to machine instead of a big interconnected pile of contours. I should be able to take advantage of multiple CPU cores to calculate them because they no longer interact with each other . Multicore roughing will probably be an early-V4 feature because it could introduce more bugs than I want in V3 right now.

The other thing that this points out is the danger of making small seemingly-insignificant changes. I changed the minimum machining margin to zero at the request of a user. It seemed innocent at the time. Unfortunately it’s now cost a lot of time to get everything working correctly on a feature that 1% of users will benefit from. I like the ability to set the margin to 0 and there will be side benefits to the fixes I have to make to support it. In another week or two I’ll be saying how glad I am that I had to dig in and upgrade the roughing to get this working. That being said, if I ever say, “Sure I’ll make that change- it’s a one-line thing” then just forward me the link to this page as a reminder.

Comments