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.
Build 6856
I managed to track down several of the big bugs that were found by users in the last preview build. It’s still not any more complete than it was before but it should be a little more usable.
1) Fixed the no-finish-path bug.
2) Fixed the huge gcode file problem.
3) Fixed the Simple Toolpath command problems.
You can download it here- http://www.grzsoftware.com/file/MeshCAM2-6856.exe .
Preview Build 6852
I managed to get everything pieced back together enough to release it as a preview. You can get it at http://www.grzsoftware.com/file/MeshCAM2-6852.exe . The finishing doesn’t have progress bars yet; that’s going to require a whole lot more code because of the new workflow and the multithreading. It does seem to work though and I’d appreciate the feedback. I’ll warn you now though, I made lots of changes so you are guaranteed to find bugs. Be sure to run everything through CutViewer.
I still have several outstanding bugs to address that have not been fixed yet. I want to get this in a stable place before I move on.
Boundary Clipping
The last few shots I’ve posted show that the toolpaths have not been clipped by the stock boundaries. The shot below shows this problem fixed. The toolpaths are properly clipped by the machine boundaries even though the clipping created new islands in the lower part of the X and in the middle of the C shape. The code also correctly handled the clipping of the existing island in the O.
This clipping task may seem simple when using a rectangle but the code is made to be very generic so that, at some point in the future, the machine region could be defined by a freeform curve imported via DXF or though a dialog. The code below just creates a polyline from the stock shape so it’s pretty simple.
This is very hard code to write if you want it to work with arbitrary polygons so I didn’t write bother- I licensed it from someone that had it worked out. A thin wrapper of C++ and it was ready to integrate into MeshCAM.
Better Surface Angle Detection
Below is a couple of shots of the new surface angle code in the parallel finishing. The angle was set for 45 degrees and it seems much more consistent than the old code. It’s also much faster to compute. There are a lot of retracts but this seems to be somewhat common for this type of path when I’ve looked at the competition. I have two ways to fix this:
1) Use a more complete toolpath linking algorithm that will make additional checks for better linking options.
2) Compute a complete offset surface of the geometry and preplan the path based on the surface angle.
#2 would give better path linking but would take much more time and memory to compute. #1 will be faster but less optimal. In the short term I’ll probably leave it as-is. It seems roughly competitive with the market, it’s still better than the current code, and I need to move on to get something released sooner rather than later. After people look at the speed of the new code they can vote for what they prefer- faster or better.
