A Bunch of Fixes
I was able to spend some time tracking down so bugs pointed out by Randy and Daniel in the last release. The odd parallel linking gouges have been solved, the surface angle bug has been fixed, and I updated the toolpath dialog to make the surface angle more intuitive ( I hope).
Here is my question to everyone:
Currently, the surface angle setting for parallel finishing is disabled when waterline is used. I can see where some would want some level of overlap between the two and the current system doesn’t allow that. I’m leaning toward leaving the separate parallel finish threshold value independent from the waterline threshold. Comments or complaints?
Build 6908
I just uploaded build 6908 to http://www.grzsoftware.com/files/MeshCAM2-6908.exe . The biggest change is to the pencil and waterline code. I hope everyone will find it to be an improvement but I do probably have one more round of changes to finish it up.
More than anything I want to this out for testing since I need to get something ready for a stable release soon. The refinement code is so much better than the last October release it really bugs me to only make it available in a beta release.
You can now check for updates with the Help->Check for Updates command. I’ll be curious to see if it works well for everyone- maybe I won’t announce even the next version here, only in the check for updates command. If the check for updates command seems error free then the next version will probably run it on startup every 5-10 runs or so. I can hear some of you starting to type an, "Are you going to let us turn that off?" comment but the answer is likely to be, "no." MeshCAM is always in a state of change and I think it’s important to keep people running the latest builds.
Persistent Bug Found
I haven’t posted much here lately because I’ve had no progress lately. I had a horrible bug that took about 10 days to find. In retrospect it should have been easier but I always say that after finding a big one. Theoretically the compiler should have generated a warning that my typo was probably a very bad idea but it never made a peep. Visual Studio is generally very good but it failed totally this time. It turned out to be a simple fix and I now have even newer pencil and waterline code.
In the course of testing the waterline code I was able to find a test case that generated bad toolpaths using a flat endmill. I had seen it before but I could only so it with a 20000 polygon file which is very difficult to debug. I think I know where the bug is but I’m still tracking it down.
I also started coding a "Check for Updates" command. This seemed like busy work but I’ve finally come to accept that it’s a must-have. It’s a shame to keep updating the program and not have everyone benefit from the changes- especially given that I depend heavily on word-of-mouth to bring people in.
Build 6903
I just posted a new build to http://www.grzsoftware.com/files/MeshCAM2-6903.exe . It includes new waterline and pencil code that will hopefully address some of the problems that people have mentioned. In my testing it seems better in every case I’ve tried. There’s still room to improve but I will be curious what to hear what others think.
Working on Pencil Code
A few pencil toolpath problems have been pointed out in the last few days. Pencil paths are difficult to make completely generic where they work well on any surface. I’ve seen some very high end programs that generate strange paths on difficult surfaces. It turns out that the standard MeshCAM model, called the "Cheese Whiz" model by some, is one of those tough cases. Although it was something I made 4 years ago in about 3 minutes it’s turned out to be a model that exposes a number of problems with toolpath algorithms.
Very steep areas can be difficult to find with the algorithm I use. I would be simple to fix this but the time it would add to calculation would be significant. I may have to add this at some point.
Areas where multiple pencil lines come together are difficult to link properly. There are different methods to deal with this but it’s not easy to make it right all the time.
This one takes a bit of imagination. When you offset the surface with a ballmill the surfaces of the ball and the rope almost merge together. This almost eliminates the type of feature that a pencil path is supposed to machine.
At first glance the path above looks wrong because it isn’t smooth but it is part of the model. The ball and the rope are very roughly tessellated in the CAD program so the intersection is not necessarily as smooth as you would expect. Because it’s a 3D path you really need to spin it around to full get it- 2D make it look very wrong.
A tighter tolerance would eliminate some of the trouble above but I’m now trying to discourage that so I have to make it work with less input data.
I point out all of the above because some of you have to be thinking, "How many times is he going to redo the pencil code?" I’ve talked to a few other CAM developers and the general agreement is that CAM development is very much an iterative process. You write code that works when you test it and wait for people to break it. Now you know a few ways to break it.
The good news is that I’m getting better results with the new code. Let’s hope everyone else does too.