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.
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.
Roughing Update
I haven’t posted an update in a while so I thought it was about time. Long-time MeshCAM users may recognize the image below. It comes from my work a year or two ago to develop a good pocketing algorithm. At the time I was a little afraid of using it in production because pocket algorithms are notoriously difficult to get correct. After letting it stew in my head while working on my “more robust alternative” that I posted in the past few months I’ve come to believe that this code was probably pretty good. The “more robust alternative” suffered some limitations that could cause poor toolpaths if given data that contained the miniscule inaccuracies that floating point numbers can have. I figured that if I have to deal with that problem anyway I should use the “correct approach” that I had been pursuing before.
Unfortunately, the code I had completed only handled the polyline offset problem. This is the bulk of the problem but there’s still the code to sort and clean up the incoming contours and islands as well as linking the offsets. The cleanup code is done and seems to be stable. It also handles nested pockets and islands properly.
The image below shows the lining problem where the collapse of the vertices as the contour is offset can lead the code to not link the offsets with a minimum number of retracts (look at the red arrow. Yellow are island boundaries, purple are the pocket boundaries). This shouldn’t be a big problem, I just have to work through it.
The ultimate goal here is to eliminate the ZMap in the roughing and provide smoother toolpaths without that “toolpath quality” option that I have in there now.
New GRZ Software Product
In a slight departure from MeshCAM related work, Apple has just made my latest project available in the iTunes app store, Aqua Match or http://www.grzmobile.com . If you have kids toddlers or preschoolers, and an iPhone or iPod Touch, then check it out and see if it’s something you might like. My three year old likes it quite a bit and I don’t think it’s because dad wrote it- he doesn’t seem impressed about that at all.
This is not a permanent departure from MeshCAM, just a diversion to get over some writers block. MeshCAM development will resume shortly with some new ideas I picked up from the iPhone game engine I used.
Offset Roughing
As I started working on the new conformal roughing a bit more I realized that some fundamental changes would be required. Starting from a clean slate I wrote a new offset algorithm to base the roughing on. Long time readers may remember that I’ve had a spent some time working on other offset algorithms. My last one worked well but it wasn’t as fast as I’d like and it always had the potential to fail since it depended heavily on floating point math (even though it didn’t in my testing). My new code is much more robust and generates much smoother toolpaths than the old roughing even though the code is only half done. It’s still far from done but I think the proof-of-concept below shows enough promise to commit to this approach for V3.
New Roughing Progress
I have the roughing simulation code working pretty well and tested to the degree that I can so far. I’ve updated the display code to let the color of the toolpath vary depending on the feedrate so the new data can be visualized. Now I just have to redo the roughing code to take advantage of all of this.
Just to set expectations early, this is not going to be a complete 3D simulation of the machining process so no attempt is made to find the “optimal feedrate”. This new code is an attempt at solving 80% of the roughing feedrate problem with the least computing time and memory required. Once I get it running we’ll have some idea how good it will be.
Based on all of your feedback I’ve made the last release an “official release” available on the main download page. Thanks for all the help getting to this point.
New Roughing Preview
Just to prove that I am working on new V3 features I’m posing a preview of the updated roughing algorithm.
You can see that the cutter will now cut the area between two Z levels to leave an even skin of stock for the finishing algorithms. This is something people have been requesting for a while so I made it the first major feature that will be released.
I am also investigating code to dynamically vary the feedrate depending on how buried the tool is in the stock. There’s no code for this part yet- it’s still in the design stage right now.
My real motivation to show this is to encourage feedback on the last release. The quicker I get that one done the quicker I can move on to releasing V3.
Build 7283
Christian K. has finally given the latest build a clean bill of health- all of the waterline problems seem to be gone. Run a "Check for Updates" and update now.
This was one of the more difficult bugs to find. It took about 10 days of deep digging to find two bugs. One was in a previous optimization that I had to partially undo. The more difficult one involved a bad interaction between the multiple threads and the Microsoft compiler optimizing part of my code away. The random waterline gouges that Christian found happen to be perfectly laid out to cause this rare bug almost every time. If have ever gotten gouges that move around each time the toolpath is calculated then this build probably a fix for it.
When MeshCAM generates a toolpath the "Analyzing Geometry" section is actually dividing the model up so it can be checked against the cutter more quickly. The toolpath is then divided between several threads, each with a separate section of the model to check. Some triangles will overlap multiple sections and can be checked by more than one thread at a time. There are some shared flags that are used to avoid conflict. Unfortunately I found that Visual C++ assumed that only one thread would ever access these flags and changed the code drastically when optimizing the output to run faster. This probably never showed up much before because users tend to have large models with lots of triangles. This would usually mean that the threads stay far enough away to not interfere with each other. Christian was the opposite- his files might only use a few dozen triangles so the potential for conflict was increased. I can say this is the first bug I’ve ever had to look at assembly code to find.