More Roughing Progress
I can say that the new roughing really is almost done now. I managed to fix the bug I posted last time and in doing so I was able to delete about a hundred lines of code and make it more reliable- my favorite kind of bug fix.
The conformal roughing option is in the dialog and working now and the mill direction setting is working. The progress bars are very fluid and interruptible which is always a challenge. I have not assigned the various level of a roughing toolpath to different CPU cores yet so I can have everyone test it before I add that level of complexity. It shouldn’t be a big change after getting feedback.
At Randy’s request the “Machine Geometry + ____” option will now accept any (positive) value with a warning to the user.
The only characteristic that I don’t like is when the conformal option is combined with very vertical surface. The nature of a nearly-vertical surface is that a small change toward or away from it can cause very large changes in the height. When the pocket boundaries are projected down onto the model they can look very ragged, especially for very course models (example below). I need more time to think about this before I can say the “correct” way to solve it is. I will not hold up the release for this since it can be avoided by if it’s a big problem on a given model.
Here is my open issue- what to call the conformal roughing option? Conformal is fine for me but I’m going to try to lower the learning curve for new users in V3 and this is not a really intuitive term. Unfortunately, I can’t think of a better one. I’ve thought about calling the option something like “Lock Z Axis” or “Use flat layers” but these are pretty clumsy. Any thoughts?
I’m going to dedicate a few more days to testing. If everything is OK then expect a release early next week.
More Updates
Work on the roughing has continued and new problems continue to popup. Luckily, the bugs are only in the difficult code- not the very difficult offsetting code. It turns out that I was getting bad contours like the ones below
I thought the offsets were the problem so I wrote a bunch of code to begin a proper 3D engine rather than the simple graphics system I’ve had for a while. I thought this would give me more options to visualize the massive amount of data generated internally by the offsetting code. Turns out to be a problem in the code to trace the outline of the geometry. That bug can be seen below-
The arrows show where the data is corrupted. It’ll take a while to figure out but I was hoping to find some bugs in this code; it worked too well from the beginning and that is always the sign of impending doom.
The time spent on the new engine should payoff big in the future since I can add more stuff to the 3D window without any effort. The new commands I’ve got in mind will benefit from this greatly if I can just finish the roughing code and move on.
Debugging the tiny details like those above forced me to look into the poor 3D behavior of MeshCAM at high zoom levels. I was able to increase the maximum zoom by a factor of 10. I’ll try more when I get more time.
A while ago I added an antialiasing option to the 3d window for users with higher powered graphics cards. It quit working when I got a new laptop with an ATI Catalyst graphics card. It turns out that my method seems have been marked “deprecated” at some point so I have to look into that soon.
My new laptop came with a bad video driver under XP (shame on ATI and Lenovo) so I had to upgrade to a Windows 7 release candidate. I can say that MeshCAM works flawlessly under that OS so I don’t expect any problems when it’s released later this year. For those readers who hate Vista, I think you’ll like Windows 7. The performance is great and it looks nice.
Finally, I was answering an email tonight and I noticed that MeshCAM turned 5 years old in April and I didn’t notice. Thanks to all of the users that have been with me over the years.
New Roughing 90% Done… Only 90% Left
The past few weeks have very productive and frustrating. The new roughing now working well and the offset algorithm has been very robust. Handling all of the special cases has taken most of the development time- every time I think I have it there’s a new special case the demands a partial rewrite. I think that most of those cases have now been taken care of and I can move forward to try and get it into a releasable state.
As of right now the roughing is functionally similar to what it was before but the resulting toolpaths should be much higher accuracy and use less memory- no more ZMaps in that code. The “Toolpath Quality” setting is now gone as well. Here’s what’s left to do:
1) Enable multicore support so each layer can be run on a different CPU.
2) Hook up the progress bars so the UI doesn’t stop when calculating. This took a little while to figure out since you don’t know how many offsets it will take to finish a layer until you’ve already done the calculations. Luckily, I found a shortcut to get a rough estimate.
3) Add an option for a “conformal toolpath” to drape the path over the model and eliminate the stair-stepping.
4) Make sure the milling direction option is honored.
Although I generally dislike adding toolpath options, I may let the user define a different tolerance for the roughing pass. This would let the calculation finish more quickly if the user doesn’t mind a higher potential for error- this shouldn’t matter since the Stock to Leave value is usually much higher than the tolerance anyway.
