Waterline Status
After the last posting it took about a hour to move the new waterline code from the test command in the photo into the main machining dialog. It worked pretty well until I started playing with the machining angle- I found the parallel and waterline were not consistent near the threshold angle. I’ve tried a number of approaches and am finally closing in on a good solution. My current approach may have more overlap between the regions but with fewer retracts and a much smoother finished part because I’m trying to maximize the path length rather than stopping a path when a surface angle threshold is passed- even if it’s only exceeded for a short span.
New Subdivision and Waterline
Randy sent me a photo of a toolpath showing a defect where the parallel finishing path would undercut when the path was almost but not quite right. I was able to fix it quickly but the fix led to a 25% increase in calculation time and I didn’t want to go backwards on that after all of the optimizing effort. I wrote a new subdivision method that eliminates the problem with a slight penalty in calculation time. After I spend time optimizing it I expect the get an overall speedup because it allows much more targeted and intelligent subdivision than the initial one.
In between that I’ve ben working on the new waterline code. It came together really quickly and is probably about 20% done already. It’s amazing how quickly you can crank out new code when you written half a dozen versions in the past. The new code is really good in the limited testing I’ve done so far. The stair stepping of the zmap is gone and, like the parallel finish, the precision is now defined completely by the tolerance value. It will still require a surface offset like the zmap offset but the time spent on each slice seems much faster even in debug mode which is much slower than a release build. Below is a photo of the output. The red arrow shows the types of bugs that can pop up that have to be tracked down.
Build 6628
I just uploaded a private release at http://www.grzsoftware.com/files/MeshCAM2-6628.exe . It has the new and improved parallel finishing code that should be nearly done- unless bugs are found. I have not been able to duplicate the waterline bugs that were sent to me but there does seem to be a new bug that adds a bunch of retracts. I’m not too worried because the waterline and pencil finish will be rewritten soon anyway. I may do waterline before pencil because of this bug.
6512 Vs. Current Code
Below is a side by side of a toolpath using the Jeff Demand Reference Model. The total area of the shots is probably a couple of mm so the details you’re looking at are very small. Both are using the same tolerance value, .025mm or about .001″. Obviously, the paths are much better in the latest code. The main change is that I reduced the amount of point reduction in the toolpaths relative to the tolerance value so that the gains from the new toolpath code are not thrown away at the very end. For an equal tolerance value the next release will generate a larger gcode file.
Just remember to reevaluate the values you typically use for the tolerance parameter when the next release comes out. I’m just fixing a few bugs and I still have to investigate the waterline problems that people have reported before the next release
Optimization Goal Reached
Over the past few hours I’ve been trying to get to the bottom of what takes so long in the new code. Specifically, the Jeff D reference model has been enlightening as I’ve reviewed the reams of data generated during a toolpath calculation. Given the hugely dense model, it turned out that I needed a way to make many of the triangles go away if I wanted to speed it up. I was able to come up with a final optimization that removed a lot of triangles without reducing accuracy in any significant way ( I won’t go into details but it’s not obvious). In Jeff’s model this led to a reduction of about 30% in the triangle count. Also, I tweaked all of the variables that define how much to reduce the points in a toolpath and when to subdivide the path. The bottom line is that I’ve reduced the toolpath calculation time from a starting point a week ago of something like 3000 seconds to 576 seconds. Additionally, the toolpaths look much better when viewed close up. With Jeff’s permission I’ll post a few photos.
People with “normal” models will also benefit from the optimizations but I don’t think you’ll see a 6x improvement.
I was about to post a new version and I noticed a bug in the tool rack dialog where the taper angle may not be shown. I think I’m going to fix that tomorrow and get the dialog to show the units of the dimensions. I never noticed the difficulty of finding the right tool when you have moth metric and English mills defined. I’m still shooting for a Friday night release… maybe the weekend if I run into problems.
Good Optimizing Progress
I just finished testing today’s optimizations on the “Jeff Demand Reference Model.” Jeff sent me a 27MB STL file with >500k triangles over a very small area about 60mm x 20mm. With the parameters that he initially provided the toolpath calculation time was over 3000 seconds- obviously way too much. After a lot of optimizing I’ve gotten it to about 1200 seconds (about 20 minutes). It’s still too much but it’s a great improvement and if I can cut it in half again then I’d be happy. Once I get everything as tight as I can then I can enable multitreading to take advantage of the multicore CPUs that everyone has not. The ZMap-based code did not lend itself to multithreading but the new code is perfect for it.
Expect a new test release in the next few days with the more correct and faster code in it.
The Optimization Continues
Thanks for all the feedback over the last week about the 6512 test release. I’ve managed to speed up the calculation by almost 50% for very large models but that still leaves them running for quite a while. I’ve made some major changes but I think I’ve still got a lot of possibility left. I hope to have another release in the next week.
Test Release
I just posted a test release of the new version at www.grzsoftware.com/files/MeshCAM2-6512.exe . I’ve spent the last half a day in a hotel room finishing everything up to the point that I believe it works will and decided that I have several users who would probably like to participate in the test process. Please run it through the wringer and let me know what you think. Here are some important notes:
1) The oversampling value now has no effect on the parallel finishing. You control the accuracy with the tolerance parameter. I would start with something like .001″
2) For historic needs, a ZMap will still be created but will not be used. Luckily, the creation of the ZMap doesn’t take much time- the offset does and that will not be done.
3) There are probably quite a few lurking bugs so don’t start machining that rare African hardwood right away without testing it on a cheaper material or in CutViewer first.
Finally, I now have an Authenticode signature on the installer and the program. This should put an end to the Vista and XP SP2 warnings about all the terrible things that a program from an unknown author could do to your computer.
As always, let me know what you think.