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.
Update
Development has been pretty slow for the last few weeks. I’ve added code to drop the process priority of MeshCAM just before it starts the finishing operations. This should help keep the system interactive during the potentially long and multithreaded operation. The priority is restored when the task is done. On an unloaded system this should not make anything take longer since Windows will keep giving it processor time as long as nothing else is running.
I’ve also been working on how to make a reliable progress bar for the finishing path. This is such a hard thing to work out because it’s all running on different cores and there are so many subtasks that need to be completed. This is a problem I’ve tried to solve before but I’ve never done it to my satisfaction because I can’t just use the same code every time without changes. This time I’m trying to spend the time to do it right because I never want to think about this again.