ZMap Elimination
There is only part of the program that uses the old ZMap code from the original MeshCAM- the parallel roughing. I started making changes today to eliminate it completely. I think it will take a few more days and then it should work. This will have two benefits- memory and speed. The old ZMap code used a lot of memory for each point that was calculated. For most cases this didn’t matter too much but lately I’ve been trying to squeeze every byte from the machining process to make the whole thing scale to larger and more complicated jobs. On a moderately complicated jobs this could be a hundred megs or more saved if everything works out. Second, I was inspired the other day when I got that big speedup in finishing paths. This could be an equal improvement for roughing. It also allows me to use multiple cores to compute the surface offset.
If it works then I’ll put out a release with the speedups pretty soon. I haven’t gotten any show stopping feedback about the last beta so I think I’m in good shape.
Tweaking for Speed
My "secret project" depends on machining a number of small objects at very high accuracy. Because of this I’ve been having out-of-memory problems on my development laptop; this required digging back into some of the deeper guts of MeshCAM that have been untouched for a while. I found three relatively simple optimizations, maybe 20-30 lines of code, that collectively lead to significant speed increases.
Below are the before and after results of my new speed test script that automates this type of testing. The speed test calculates a parallel finish toolpath on the standard "cheese whiz" model 5 times and averages the results. The 30% reduction may or may not be typical but all finishing toolpaths should benefit.
Memory use should also be reduced somewhat during toolpath calculation.
UPDATE: Ok, maybe not 30%. I found a bug that required me to give back part of that optimization. Count on something more like 15%.
UPDATE TO THE UPDATE: Ok, maybe better than 30%. I found another place to shave off some time and I exceeded the count above. The new best time is about 10 seconds so the current improvement is about 36%. Let’s hope I don’t find any new bugs that make be have to give that up.
What’s New
I haven’t posted much here but there has been a lot of work lately-
- Updated wxWidgets to 2.8.7
- Added wxLua so the GUI can be written in scripts without recompiling the program.
- Updated the manual system to allow easier translation.
- Added an exclusive distributor for Italy.
- Added a reseller of a rebranded version of MeshCAM. They sell 3d clipart and want to provide a "turnkey" solution.
- Added support for multiple languages in MeshCAM. German and Italian should be available soon, Spanish sometime after that.
- Added a new testing framework- Google Test
- Added a whole new build system to allow greater automation and flexibility in the build process.
- Fixed a bunch of interface quirks pointed out by Moriarty in the user forums.
- Cleaning up the version control crud that has built up over the past few years.
People who have been users for a long time will notice that the release cycle tends to be very uneven. I spend a while doing a bunch of plumbing with only a few releases followed by rapid releases of new features and bug fixes. The goal of the work above is to clear out the todo list of many of the boring tasks so that I am able to push everything forward quickly.
I am waiting for translation files from my distributors before the next release. After I get them and test everything I’ll post a release here for review and then, hopefully, I can release it as MeshCAM 2, call "done" and move on to MeshCAM 3. That version change doesn’t have much meaning for users- it has more to do with my need to have a more stable release schedule like the rest of the market.
What I would like to get more feedback on are quirks that have annoyed you over time. Moriarty has outlined a bunch in the development section of the forum and I’d like to get more knocked off in the next few weeks. I can’t promise that everything will be fixed in the short term ( some have deep reasons that take time to address) but I would like to know what you think.
More Scripting and Other Updates
I’ve been adding more scripting functions like the ability to offset an STL after loading it. The image below shows my test case for that function. You can see where my laptop ran out of memory and couldn’t load any more. I was running under debug mode where the memory requirements go way up.
I’ve also been working on making the waterline toolpaths cut in a depth-first order where, in the case of multiple cavities, each cavity is cut to full depth before moving to the next. There are tons of special cases that people will want to be "optimal" and won’t be. It will be a big speed boost for many people though. For the time being it will be optional through the Lua interface because there’s a lot of testing to make it reliable.
I also got a note and photos from a user today who has just completed cutting a large die casting tool from hard tool steel using MeshCAM. To be honest, I would never have recommended this (given the cost of the steel) if he had asked me before trying it but MeshCAM worked very well for him. I’m trying to get permission to share the photos on the web site.
Check Surfaces / New Release
I’ve been working for a few days with a large company to see if MeshCAM can be used to automate their machining process. They have a few things that need to be added and then a bunch more existing features that will have to be exposed via the Lua scripting. Largely these changes match my existing plans so I’ve decided to give it a shot.
The first change was the need to add Check Surfaces. These are additional polygon/STL surfaces that are used to represent things like tooling, shutoff surfaces, and parting surfaces. The tool is never allowed to gouge them but they do not necessarily represent a feature of the final part.
An example of their use is shown below:
The sphere on the left has a hole that would be better drilled than parallel milled. You can always drill after parallel machining but it may be better to protect the edge and not plunge into there at all. The photo on the left shows a check surface that was saved as a separate STL file and loaded with the new "Load Check Surface" script. There are two different surfaces- a plug for the hole and a wavy surface that could represent a complex parting line. The important thing to note is that they do not count in the geometry dimensions(note the stock dimension do not change) - they are only used in the toolpath algorithms as an additional intersection test.
Practical uses for this feature-
- Modeling a vise, clamps, or a machining fixture
- Capping areas that would be poorly machined or that would be only partially machined
- Limiting the machining volume to the minimum required by defining a "parting surface"
- Defining your own tabs or supports
There is a second script that removes the check surfaces without changing any other parameters. This may be useful if you have a more complicated machining strategy in mind.
In the very near future the scripting ability will be expanded to allow offsetting and rotating the check surfaces. Scripts will then be able to do things like automatically place vise jaws so they touch either side of the geometry to simulate clamping.
Download it at http://www.grzsoftware.com/files/MeshCAM2-6926.exe or check for updates.
Finally- Save Toolpath Settings
I’ve been trying to work through some problems for Brett P. and he got me thinking that I need a way to duplicate as many user settings that a customer uses to reproduce some bugs. This got me thinking more about the Lua code I’ve got built it and it turns out to be a very good data parser. I was able to implement the ability to save and load toolpath settings in about two afternoons once I figured out how I wanted to do it. The data is all saved as a Lua table which is editable outside of MeshCAM if you want.
I have to do a little more to save the tool properly. It currently saved the tool index in the saved tool list. It will be changed to save the complete tool info.
I just need to add error checking and the tool functions and then I can release it.
UPDATE: Turned out to be relatively easy- it’s all working now. I just need to add some error messages for failures.
New Support Forum
I just got done adding a new support forum at http://www.grzsoftware.com/forum . Yahoo Groups was fine 3 years ago, but it’s looking pretty unprofessional to have it hosted there now. It’s also painful- for me at least- to browse through everything and keep up to date. Hopefully this new forum will be better for everyone.
It would help if readers here can go create accounts, log in, and poke around. If it seems to be working then I’m going to change the link on the website over and make it so no new posts can be added to the Yahoo group.
New Update
Run the Check for Updates command in 6908 and let me know how it works.
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.