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.
Installer Fixed
With the help of a handful of dedicated users I now think I’ve gotten tot he bottom of the "Can’t save registration information" problem. It turned out to be an installer mistake a few releases ago that left bad data behind. A new release at http://www.grzsoftware.com/files/MeshCAM2-6901.exe should fix the problem. There are several other fixes so try it and let me know what you think.
One More Release
I just uploaded another to- http://www.grzsoftware.com/files/MeshCAM2-6897.exe
It fixes the following items:
1) Fixed error where settings were not saved on exit. Turned out to be an installer problem.
2) Tool list is now saved after any change or addition to the list (Randy G-G).
3) Hopefully resolved an assertion error in cl.cpp that could occasionally occur. (Jeff D.)
Let me know if it works better.
The Ripples Continue…
The waves of change created from the toolpath refinement updates have now hit the waterline and pencil code. The code that pieced together the waterline and pencil paths was written for the old refinement code and, as Adam demonstrated, left something to be desired with the new refinement code. It turned out to be a < 1 minute fix after tracking down the problem. The photo below shows the output- note the smooth output and the lack of little path segments.
Jay pointed out some unintended changes to the roughing code. It turned out that the new polyline simplification code was doing something funny to the outline contours. I reverted to the old code until I can sort out the problem in more detail. Thinking about that problem led to the thought that encouraging people to use a larger tolerance value because of better finishing code will lead to lower-quality roughing paths. To equalize this I increased the internal quality settings for the roughing to make them better for a given tolerance value. hopefully this will make the roughing and finishing quality more on par with each other.
Randy’s pleas for a better place for the MeshCAM shortcut have been recognized. I updated to the new Microsoft-preferred location of putting the program directly under Start->Programs and using Add/remove programs for the uninstaller- no more uninstall link in the start menu.
I can’t duplicate Jeffs bad x-size problem. I need to reinstall Rhino on my laptop so I can investigate further.
I uploaded resulting update to http://www.grzsoftware.com/files/MeshCAM2-6895.exe .
The todo list before the next public release is:
1) Update manual
2) Add warnings for excessive tolerance values (with the option to not be warned in the future)
3) Find Jeffs x-size problem
If I’m missing anything big please let me know- I probably lost the email.
New Test Release
I just uploaded a new test release that includes the fixed toolpath refinement and updated tolerance code. I would suggest that you not set the tolerance below .001" to start with because that will now give a much better finish than before. You can download it at http://www.grzsoftware.com/files/MeshCAM2-6887.exe . Let me know what you think and what the calculation times end up being for an equivalent quality (not equivalent tolerance) toolpath.
No other bugs have been addressed. I will being working through some of them now so I can get this ready for a public release. I may be contacting some of you who’ve made bug reports for more information now that I have time to address them before the next release.
Lurking Bugs
It always seemed a little odd to me that I had to set the tolerance below .001" to get a toolpath that I liked. A thousandth of an inch, in general, should be more than enough accuracy for almost any "normal" application. It wasn’t until the last batch of updates that I came to my code to reduce the number of vertices in a polyline and found old code that I thought had been updated long ago. There was potential for the polyline to be eroded away beyond the tolerance setting specified that needed to be fixed- or so I thought. I rewrote it to work properly and found almost zero improvement. Oh well, at least it’s correct now.
I making this change I was led to an error in the last release where the finish path is reduced by a factor of about 25 more than it should be. It should only be present in the last 2 test releases- never in a download from the main page.
That led me to the toolpath refinement code. It turned out that there was a massive bug that led to toolpath points being put in non optimal places. This meant that you needed to move the tolerance way down to get a really accurate toolpath. This can be seen in highly concave corners where the exact corner is not found. This could be what some have seen when they noted a problem with the pencil toolpaths.
The point here is that the next release should have greatly improved accuracy for an equal tolerance value. I’ll mention it again in the announcement for when I post it but you will almost certainly have to adjust your tolerance values up to hold your old toolpath quality and calculation time. For the tolerance freaks reading this, and you know who you are, this should be a great fix. I hope to get it out in the next week.
UPDATE
Ok so it turned out to be easier to complete than I thought so I’ve posted a shot below of the results. The corners show the benefit of the changes.
I also realized that the waterline paths should be more accurate too. People with homemade routers may not notice the changes but I think it’ll be a big deal for those with a more rigid machine.
I’m not sure what this will do to calculation time overall so I’ll have to test more. I suspect that the calculation time for a given quality of toolpath will go down. The good news is that the changes to the refining code should make it very feasible to make it support multicore for that step as well.
Updated Progress Bars
I finally got time to finish the progress bars in the parallel finishing toolpath code. It’s pretty good and it should be generic and it’s multicore-friendly so I can transfer the code to other parts of the code as they are converted to support multiple cores. It’s also helped me find some areas of opportunity for further optimization since the progress bars are updated to show what step is being executed at a given instant.
You can download it at http://www.grzsoftware.com/files/MeshCAM2-6868.exe
I think this can be considered a release candidate for the main download page pending feedback from people who try it here so I am very interested in feedback.