Offset Pocketing
Offset pocket algorithms have always been a problem for me. I spent a lot of time writing 3 or 4 different chunks of code and all have had problems. Anyone who’s ever written one will tell you that they are extremely difficult to get right because of the limitations of floating point numbers. Academic papers have outlines inconsistencies in several very high-end modeling kernels when it comes to generating offsets. A second problem that applies to MeshCAM more than some other 2D programs is that the pocket curves generated by it can be huge– this causes so much intermediate data to be generated that it’s difficult to debug any errors. I had finally decided that I would never have any offset pocket code that I could feel comfortable unleashing on my users. Instead I implemented zig-zag pocketing in a way that should be nearly bulletproof after it’s been put through use for a few months.
While waiting on a long recompile the other day I was going through some web links I had accumulated. I came across an old code library, made for a totally different purpose, that I could apply to the pocket problem. Within a few hours I had the basics of a working pocket algorithm that has yet to fail. The best part is that it only took 300 lines of new code I don’t have islands supported yet but that should be relatively straight forward. If all goes well then I’ll go ahead and license the library and include it in MeshCAM as a roughing option.
For those who are interested I’ll point you in the direction of the paper that gave me the initial idea here: www.me.berkeley.edu/~mcmains/pubs/DAC05OffsetPolygon.pdf . My implementation is very different but the approach in the paper is different enough than the usual ones that it sent me in a new direction.
Build 5934
I just uploaded build 5934 to http://www.grzsoftware.com/files/MeshCAM2-5934.exe . It will not appear on the main download page since the roughing code is still relatively untested. Please send me your feedback so I can address any problems.
Roughing Revision 2
I just finished a recompile of the new roughing code integrated with the existing waterline code and it seems much more stable against several of the bugs that people pointed out. There is still potential for problems but I haven’t found anything but some unneeded retracts. Once I get the code tested by a wider audience I’ll try to track down the extra retracts.
I just emailed the code to one of my better testers who gave me some specific problems in the last release. If he gives it the OK then I will probably post a new version in the next two days.
Also, as expected I found some really basic bugs in the waterline code that would lead to some extra retracts and longer toolpath calculation times. It turned out to be a two minute fix once they were found.
Long Week Coming to an End
Updates to MeshCAM have been slow for the last week and a half since I’ve been at a factory in China or with manufacturing agents in Hong Kong for most of that time. I tried to find time to go to the factory mold shop and get some photos to post but I never had time. I did manage to get a shot at the company dorms off of the roof of the building I was in. (I was lucky enough to get back to my hotel in HK every night.)
Back to business- the last release was found to have some bugs that I didn’t encounter in testing the new roughing algorithm. Users have supplied me with files and settings that allow me to reproduce the problem. Although I initially thought it would be a quick fix, the problem turns out to be more complicated than expected. There are some bad assumptions in the code to extract the borders of the geometry at each level of roughing. This was new code that I wrote for the roughing rather than to use the same code from the waterline toolpath code. Instead of fixing the new code I’m going to adapt the waterline code to be used for roughing as well. I expect this will also allow me to improve the quality of the waterline code.
Build 5681
I just posted build 5681 to www.grzsoftware.com/files/MeshCAM2-5861.exe . It will not appear on the normal download page until I get some feedback since there are big changes due to the new roughing algorithm. Please provide feedback as you test it.
No More Duplicate Offsets
As I was going through all of the code to make the new roughing algorithm work I figured now was a good time to remove the problem of redundant offsets if two passes, like a parallel finish and a pencil pass, use the same tool. It was a deeper change than I anticipated so everyone will need to keep an eye out in the next release for quirks.
Roughing and finishing will probably require separates offsets since the new roughing code mandates a specific ZMap spacing that is usually different from the finishing pass. Nonetheless, it should result in a significant reduction in the time spent calculating a toolpath.