If you’ve been watching the download page, you’ve seen a lot of updates in the past week for V7. After lots of R&D, experimenting, and customer feedback, V7 is the most stable it’s been in a while. If you’ve been waiting for a good time to try it out, now is the time.
By Rob G. on Tue, Jun 26, 2018
I just uploaded what I hope will be the last build of V6 before I make it an official release. This happened to be a big change- at the last minute I decided to change to Visual Studio 2013 from Visual Studio 2005. My thinking was that C++ has advanced a lot in the last 10 years and MeshCAM can benefit from the new C++11 features. To use this features, I needed to move to a new compiler.
By Rob G. on Wed, Jun 18, 2014
The next few weeks should bring the first public release of MeshCAM V6. It will be a bit more of a work-in-progress than other releases, with features being added over time rather than at the start, but the changes required to make MeshCAM work on a Mac were too invasive to keep it in the V5 path.
By Rob G. on Mon, Jan 20, 2014
I just uploaded a new build, number 43, with two big features: inside-out Waterline and Pencil Finishing and new code to make the Pencil Finishing cut direction match Waterline better. Inside-out cut ordering has been another highly-requested feature in the past year. The fact that this is such a common request reflects the growing use of MeshCAM for 2D work. Years ago I never would have anticipated MeshCAM being used for 2D work but it’s become very common.
By Rob G. on Fri, Sep 20, 2013
By far, one of the most requested features in MeshCAM is a way to define a keep out region using the Set Machine Region command. If you’ve emailed me about this in the past I may have given you a few suggested workarounds but I never had a suitable answer other than, “It’s in progress.”
By Rob G. on Fri, Sep 13, 2013
If you’ve been run the “Check for Updates” command lately then you’ve seen a few new releases come out that I have not announced here. They included the new Drill and Cap Holes commands. These commands are somewhat complecated and untested so I wanted to get gradual feedback as new people found them rather than the kind of inbox-crushing feedback that can happen when I announce them here.
By Rob G. on Mon, Jan 07, 2013
I’ve promised a drilling mode for a long time and I’m happy to say that it’s almost ready. Drilling is a feature that should be very easy compared to all of the other toolpath options in MeshCAM. From a technical point of view, it is- from a user interfaces point of view, it’s very difficult. Here are some of the problems that have held me up:
By Rob G. on Wed, Nov 28, 2012
I just saw that Cubify, a division/product line from 3D Systems has released Cubify Invent to support their Cubify 3D printer. For those who haven’t followed them, 3D Systems has bought a number of small compaines making software or low-end 3D printers in the past few years. One of the companies they bought was Alibre, makers of a very affordable parametric CAD program.
By Rob G. on Wed, Jul 25, 2012
The following is not MeshCAM related, I’m posting it here with the hopes that it will save some other Solidworks user the hour it took me to figure this out. Just a warning though- do this at your own risk since it involves registry editing.
By Rob G. on Tue, Jul 10, 2012
One of the other CAD/CAM vendors posted a part in the CNCZone and challenged other companies to show how easy (or difficult) it would be to machine the part with their system. I didn’t want to leave the challenge unanswered so here’s “The MeshCAM Way”.
By Rob G. on Wed, Jun 20, 2012
Version 5 is no longer a beta! I just posted a new release that eliminates all timeouts and enforces the license codes. If you bought MeshCAM or a V4 upgrade in the last year then you get Version 5 for free. If you have a code for MeshCAM Art then you’ll also get Version 5 for free. If you don’t qualify for a free upgrade then you can go to the upgrade page to get a discount on a V5 license.
By Rob G. on Mon, May 07, 2012
If you’re reading this then I did my job correctly and you’re connected to a new web sever. While I had no major problems with my old web host, it was time to move on. They had a really funky and slow control panel that made simple changes very tedious. I had also been seeing random 10 minute outages. While 10 minutes here or there is not a big deal, I never knew if it was an outage on their end or if it was something specific to my site. They were never transparent about server status and their support was what one would expect from a standard shared hosting plan.
By Rob G. on Thu, Feb 23, 2012
A couple of days ago I got an email from Michael Hilimire, a new user, and he was kind enough to share some photos of the work he’s been doing with MeshCAM. Michael builds custom guitars using CNC equipment and the photos looked so good that I asked permission to post them here.
By Rob G. on Tue, Feb 21, 2012
I just published the first build of V5 at http://www.grzsoftware.com/dl . This includes lots of internal changes to support the coming V5 features as well as:
64 Bit Support
A new “Automatic Toolpath Wizard” in the main toolpath dialog
By Rob G. on Mon, Aug 01, 2011
With all of the powerful CAD/CAM programs out there, one of the most common tasks is the conversion from DXF to g code. Frequently there is no need to pocket or face the stock- just cut out the objects in the file from flat stock. Given this simple task, many CAM programs look like overkill. Can we make this common 2D task easier with 3D CAM software? Yes we can.
By Rob G. on Mon, Jul 18, 2011
In the circle of engineers and companies that I interact with, most use SolidWorks as their CAD program. I do know one or two using Pro/E or NX but they’re the odd cases. A few years ago I had the need to move up from Rhino, a great CAD program that is a great match with MeshCAM, to a parametric CAD program. My desire to interact with all of these other users, and a great leasing deal at the time, led me to buy a copy of Solidworks. It has been a great tool to have and it works great with our CAM Software. Hopefully MeshCAM will be a first-choice when you need CAM for SolidWorks.
By Rob G. on Wed, Jul 13, 2011
I’m making constant progress on V5, flipping back an forth between deep, hidden changes, and superficial dialog changes. The dialog changes are needed because one of my goals for V5 is to really simplify the parts of MeshCAM that ended up looking like an engineer designed them. One of the best examples of “engineer-designed” is the Set Max Depth dialog:
By Rob G. on Thu, Jul 07, 2011
After a long time I finally figured out how to get a working 64 bit build of MeshCAM. It ended up being a random setting I put in Visual Studio years ago that prevented the build from succeeding until now. I now have debug and release builds of MeshCAM 64 and they seem to work very well including the ability to use tons of memory:
By Rob G. on Thu, Jun 02, 2011
One of the fundamental parameters of any CNC machining, and 3D machining in particular, is the stepover. It is not a stretch to say that it is the single most important parameter in determining the quality of the finished parts you will produce. A machinist can pick a value by feel, based on previous experience, or do the math and calculate the exact value that will give them the finish required. New users generally don’t have the experience and don’t know the math so it takes a while to get an intuitive understanding of of the stepover parameter.
By Rob G. on Mon, May 16, 2011
I get two questions over and over: “What is the surface angle limit?” and “Parallel finish leaves ragged edges, what can I do?” Each question is really the answer to the other but it’s something I’ve had a lot of trouble communicating. Here’s my latest attempt complete with pictures…
By Rob G. on Tue, May 10, 2011
New users frequently ask questions about how to set a program zero for a toolpath. Most will just accept the defaults and see what happens. Luckily, the default program zero in MeshCAM is very safe, and most users begin with very forgiving jobs, so everything usually works out fine. Once you get a few jobs done and get a better understanding of the process there are real benefits to picking the right program zero for a job.
By Rob G. on Mon, May 02, 2011
The latest updates have been mainly been bug fixes as I try to “complete” V4 so I can take a break and then start V5. The bug reports have been slowing down so I think the trend is heading in the right direction. I’ve been getting more and more people who are running against the 2GB memory limit imposed on 32bit Windows programs. Most of the time this is a problem with the settings they’ve chosen but there are a few people who are looking to do really big work with MeshCAM. Since I had been planning to add a 64 bit version in the future I figured I’d just try to compile it as 64 bit to see what happened. Hours and hours of little changes, finding out how to rebuild all of my 3rd party libraries as 64 bit, and removing old code that I didn’t need anymore and I can start to see the light at the end of the tunnel. Part of the problem is that I build all of my release code with Visual Studio set to treat warnings as errors. Many of the warnings you get when you move to 64 bit are warnings that will never cause any trouble in MeshCAM. That being said, I’ve put a lot of work over the years in my “warnings are errors” policy and I’m not eager to relax that now even for 64 bit builds.
By Rob G. on Mon, Mar 28, 2011
I just uploaded a new build with a couple of significant changes to http://www.grzsoftware.com/dl . First, small bitmaps will no longer be “optimized” for machining. This optimization was used to reduce machine time and it works well unless you use low-resolution bitmaps. Now, if you have a bitmap with an edge resolution less than 200, no optimization will be used.
By Rob G. on Thu, Feb 24, 2011
Astute website watchers may have noted the page I added, Linux CNC . I’ve spent some time with the latest Ubuntu/EMC2 distribution from linuxcnc.org and I can report that MeshCAM works well on that OS using Wine, the Windows emulator included in the distribution.
By Rob G. on Wed, Jan 26, 2011
I’m uploading Build 36 now and it has a couple of small fixes. First, it fixes some rendering problems that were introduced with the ortho projection in the last release. Two, Richard in Germany sent me another file that caused a problem with the toolpaths. There was a potential for a nearly-vertical triangle to cause spikes in the toolpaths. I think I fixed it but you’ll want to be very careful in this release to make sure I didn’t cause any side effects. Let me know what you think.
By Rob G. on Thu, Jan 20, 2011
I got my first complaint about the new edge rendering today and was asked to add a way to disable it in the next release. If you don’t like the edge rendering you can disable it now by creating a file called** init.lua** in c:\program files\meshcam4\scritps with the following line in it:
By Rob G. on Wed, Jan 12, 2011
A couple of users have made me aware of a new problem I’ve created with the Define Region command- if you have many parallel surfaces that are offset in the Z dimension they all blend together when you view them from above. This makes it very difficult to accurately place the machine region where you want it. I am uploading a new build that has added code to detect sharp edges and draw them separately. The effect can be seen below:
By Rob G. on Mon, Jan 03, 2011
Just uploaded my second release today to fix the remaining jags in the arc connections. The fit should be more accurate than before. I have a couple of more things to verify and then I can finalize the UI and ship it. Let me know what you find.
By Rob G. on Tue, Nov 30, 2010
I’ve been getting complaints from users that the waterline toolpaths cause the program to lockup lately. I haven’t been able to repeat it on my machine until I get an email from Florian today. Something he said jogged my brain a bit and I realized that the problem was with the new multicore waterline code. Single core machines would freeze but machines with more than one core would work fine.
By Rob G. on Tue, Nov 30, 2010
I just uploaded another V4 release. This one has a couple of feature updates, including arc fitting for pencil paths, but the big thing is the increase in accuracy. There are a number of things that I tweaked internally to achieve this. I have been wanting to do this for a while and the arc fitting turns out to be a good reason. In general, if you used .0001” before, you can increase this by a factor of five in this release or .0005”. My goal is that most users will never have to go below .001” unless they are doing very detailed parts on a very good machine.
By Rob G. on Mon, Nov 29, 2010
I’m uploading a new build with (hopefully) improved arc fitting right now. I’ve redone the arc fitting about 5 different ways from the last build and I think I finally have something that I can call an improvement. To get the quality where I wanted it to be I had to crank up the internal toolpath quality in this build.
By Rob G. on Tue, Nov 16, 2010
It’s been quiet here for a little while but work has quietly been progressing on the arc fitting code. I got feedback from a number of users who demonstrated cases where my code failed to produce good results. I would call my first release of the code a “one-pass” arc fitter. My new code is taking the output from that code and trying several optimizations on the toolpath to make it as smooth as possible. I ran my first real toolpath today using the code and it seemed to run really well. The mill seemed to handle the arcs much better than the linear paths. The testing was very non-scientific because my mill just got a control upgrade because of a blown VFD; it might also have been the corresponding upgrade from Mach 2 to Mach 3. (A word of warning to Tormach users- if you have the analog VFD then you can look forward to a failure like mine when the pots get old and dirty) Testing will continue and I expect a release in a week or so.
By Rob G. on Mon, Nov 01, 2010
The version posted yesterday is likely to be the last before the “official” first release of V4 in about a week. That current version has a 60 day timeout and no limitation on registration codes. Please try it out and give me any feedback you can.
By Rob G. on Wed, Oct 20, 2010
I uploaded the latest release to http://www.grzsoftware.com/dl . It features both the arc fitting and the multicore waterline code. I need to warn everyone that the UI for arc fitting will change- I’ve given you too much power right now (just kidding, it is too complicated for the newbies though). It will likely change to a single drop down like- Arc Fitting: None, Low, Medium, High where Low, Medium, and High cause the arc fit tolerance to be some predefined multiple of the global tolerance. From what I’ve seen in my testing, this may even be too much, it may be enough to just have “Faster” and “More Accurate.” I would like to get feedback from everyone on what they decide to use for both the global tolerance and the arc fit tolerance so I know what those multiples should be.
By Rob G. on Tue, Oct 19, 2010
As usually happens, the arc fitting ended up being more tricky than I initially figured. It turns out that finding an arc is easy, finding a “good” arc is hard. Right now the code is working well enough for me to call it a good first release. To get to this point I had to throw a lot more math at the problem so it slowed down more than I wanted. Coincidentally, I just got a new quad core laptop and I’m looking at only one active core during that arc fitting- definitely not good. Since my waterline code is ripped apart right now I decided to just take the plunge and enable multithreading for waterline in the next release.
By Rob G. on Thu, Oct 07, 2010
One more feature I’ve been compelled to add for version 4- arc fitting on waterline paths. This has been a request for a while and it never seemed to be that important from a competitive point-of-view or in terms of the reward given the development effort. A couple of things happened in the past month to change this.
By Rob G. on Tue, Sep 28, 2010
I am in the process of uploading a new V4 build to fix a problem that I’ve seen before but I didn’t know exactly how to replicate until today. There was a bug where the waterline path linker could run the tool into uncut stock if the “Machine Geometry +” was used with the right type of model. It’s tough to describe so I’ll post some pictures below:
By Rob G. on Fri, Aug 27, 2010
I just uploaded V4 Build 15 to http://www.grzsoftware.com/dl . It includes a few fixes for bugs found by Gerry and some optimizations that I made internally to save memory and speed up processing. This fix seems to be significant for the “Linking” part of the toolpath calculations and when you save a toolpath. I hope to find a few more big wins like this in the next few weeks.
By Rob G. on Tue, Aug 17, 2010
I just uploaded V4 build 12 to: http://www.grzsoftware.com/dl . I made a number of little changes to the UI and one big functional change, the new “Set Machine Region” command. You can now define one of more regions to contain the toolpath without having to pull the trick of shrinking the stock to fool MeshCAM. I think this will be a huge benefit and that it will see lots of use. You can also load a DXF file but please note that only DXF V12 is well-supported. Later versions can be hit-or-miss.
By Rob G. on Wed, Aug 11, 2010
I just uploaded the first build of V4 to the normal location, http://www.grzsoftware.com/dl . I think it should be stable enough to use regularly and it will install next to V3 or V2 without overwriting anything. Just be aware that this build will expire in a month so you’ll have to download the new versions as they are released to try them.
By Rob G. on Tue, Jul 20, 2010
When I was asking my resellers for requests for V4, one of the guys in Japan asked for the ability to load 2D DXF files and machine them. In the past I have always stayed away from 2D stuff because MeshCAM was never made to do it. In the past couple of years the waterline and pencil have gotten good enough that I think the feature would be useful. If you try to load a 2D dxf file you will get the following dialog:
By Rob G. on Fri, Jun 25, 2010
It isn’t often that I get a really strong statement from Gerry but he made a really good point about my new units dialog- he doesn’t ever want to see it and the more I thought about it, most people never need it since they don’t change units very often. For Gerry:
By Rob G. on Fri, Jun 18, 2010
I’ve spent some time working through the todo list for V4 in the past few days. One change, that may only be important to me, is to have the units dialog show the size of the geometry to be loaded. I thought this would be important because I regularly get files in both mm and in and I usually do not know what units were used until I open this file. By looking at the magnitude of the units, it’s pretty easy to tell which it is.
By Rob G. on Fri, Jun 04, 2010
I’ve always disliked the slice command in MeshCAM until now; it’s ugly, unclear, and inefficient. The Customer Experience Program showed moderate usage even in this sorry state so I figured it might get real use if I made it better. The new slice command is not just a trick of defining the stock to only machine one slab (like the old command), it will instead save a batch of STL files- each one representing one slab of the model that can be loaded and machined separately. An example of one of the STL slabs is shown below.
By Rob G. on Thu, May 13, 2010
Unless I get any negative feedback in the next day or two, V3 is going to be moved to the “stable” download branch and V2 will go away forever. If you have a chance to run the latest V3 through it’s paces before then I’d appreciate any positive or negative feedback.
By Rob G. on Mon, May 03, 2010
I just uploaded V3 Build 17 to the normal spot, http://www.grzsoftware.com/dl . It includes the latest roughing spike reduction code. It’s not quite perfect but the last 1% are tough to remove. I’d have to dig pretty far into the code to remove the last few. I hope your testing will confirm that this is a big improvement.
By Rob G. on Thu, Apr 29, 2010
I just uploaded build 16 to http://www.grzsoftware.com/dl . I fixed the roughing spikes a little and am now working on getting the rest done in the next day or two. A wanted to float this release in the mean time to see if others agree that it seems like an improvement on their parts. Let me know what you think.
By Rob G. on Tue, Apr 20, 2010
Several users of the 3D roughing option have pointed out the spikes that can appear near the geometry. On first glance, they look like a bug in the code that projects the toolpath down to the surfaces. The problem is actually microscopic movements in the toolpath in the XY plane.
By Rob G. on Sun, Apr 18, 2010
I just uploaded build 15 to fix a problem that Jeff and Martin found. I put a debug assertion in the code to check for a condition that “can never happen.” Jeff and Martin both found a way to make the impossible possible. I’ve removed the assertion and tried to handle the case properly so give it another shot and see if you can make it fail. Check the toolpaths carefully to make sure I haven’t done anything dumb.
By Rob G. on Mon, Apr 12, 2010
I just uploaded build 14 to http://www.grzsoftware.com/dl . This build includes two big things- memory and speed optimizations and the new roughing code. Both features have been tested but could contain hidden bugs. For the memory and speed optimizations, I’d be curious to know if you see a difference since build 13. Both will depend on the models you’re using and, since small models run incredibly fast already, I’ve focused more on the big ones.
By Rob G. on Sat, Apr 10, 2010
I was able to add the new code I’ve been working on into the main roughing code and, so far, it seems to work well and break nothing. That’s a good thing because the fix ended up being more invasive than I hoped. I’ll probably be testing it over the next week and the uploading a new build at the beginning of next week. For now, you can see the before and after pictures below. Again, this was done using the special case of setting the “Machine Geometry +” to zero.
By Rob G. on Thu, Apr 08, 2010
I mentioned in the last post that I found a bad bug in the parallel roughing and that I had been working on resolving it. At the time I still hadn’t even figured out the cause of the problem but hours of staring at debug data finally showed the conditions that cause it: “Machine geometry + “ set to zero. By now I’ve forgotten why I even used this setting but I used it with a very complicated part that contained check surfaces so it took a long time to understand the problem and the exact conditions that caused it. I thought I understood it last time I posted but I was off by a bunch.
By Rob G. on Thu, Apr 01, 2010
Following the last burst of updates, it might appear that I’ve taken a break lately. Unfortunately, I haven’t gotten a break- I’ve been trying to track down some ugly bugs that I found in the roughing code while helping a friend machine a bunch of parts. It took a couple of weeks to find the root of the problem- it turns out that using a “Machine Stock +” value of 0 can lead to some really incorrect paths when check surfaces are used. This might be an edge case but I really had no idea what combination of settings caused it until yesterday. Now that I have it narrowed down I should be able to fix it pretty quickly.
By Rob G. on Tue, Mar 02, 2010
I just uploaded build 13. It doesn’t contain any new user functionality- just a bug fix on a problem that Richard in Germany found and the addition of a new license code system. Old codes will continue to work (if I haven’t made any mistakes) but a new system will be rolled out when I can move V3 to “release” status. I get some pretty odd support emails regarding registration so I’m hoping this new system will give users better feedback about what might be wrong if they are having trouble.
By Rob G. on Mon, Feb 15, 2010
I just uploaded Build 11 with a couple of fixes for old post processor bugs and one memory optimization for models with a large number of small triangles. I was able to complete a toolpath from an STL with over 1.8 million triangles so this is a noteworthy improvement.
By Rob G. on Tue, Feb 09, 2010
It’s been pointed out to me that my comment a few days ago, “I’ve just ended the dumbest event in MeshCAM development in a long time” sounded like I was criticizing the user for having an older CPU and expecting it to work forever. This is absolutely not what I meant. The dumb part was that I did not take the time to read the change log or this blog earlier in the debugging process. If I had, the whole thing could have been cleared up very quickly. Sorry for any misunderstanding.
By Rob G. on Mon, Feb 08, 2010
The title says it all. I’m adding some features that will require the loading of 2D DXF files and I need to get an assortment to be able to test my code. All CAD programs tend to do things a little differently and DXF files are really a pain in my experience as a CAD user. Ideally, I would like the following:
By Rob G. on Fri, Feb 05, 2010
I’ve just ended the one of the more humbling events in MeshCAM development in a long time. I got an email from Richard in Germany saying that he recently applied a WinXP update and MeshCAM now crashes immediately upon startup. Build 5 worked but the later ones failed. This is one of the most difficult cases to debug since it’s impossible to reproduce and I don’t have access to the machine. Also, the change from Build 5 to Build 6 coincided with me getting a new laptop so I immediately assumed it was a problem with my build environment or related to the XP update.
By Rob G. on Thu, Feb 04, 2010
And now something that I expect to cause controversy… The Customer Experience Program. Users of many programs, including WinZIP, MS Office, and Solid Works, have probably seen the installers ask for permission to share your usage data with the company. Until the last few weeks I considered this an imposition and generally didn’t participate.
By Rob G. on Thu, Oct 29, 2009
I just uploaded build 8 to the standard location. It fixes a bug that Randy found and adds the option to drag and drop a 3D file onto an already-open 3D file. This will give you the option of opening the new file or inserting it into the current file as a check surface. This is good for times when you want to define your own supports in a CAD program of if you want to add a shut-off surface to an open area. This capability has been available via scripting but it was never a first-class function so I don’t think anybody ever used it. Hopefully this will be better.
By Rob G. on Wed, Oct 28, 2009
I just posted build 7 to the normal location, http://www.grzsoftware.com/dl . It includes a bunch of fixes and major performance improvements. It is also a nearly-complete build of V3. The only changes from here will be bug fixes, documentation updates, and translation updates.
By Rob G. on Mon, Oct 26, 2009
I’m trying to get V3 R7 ready for release on Friday and I need some help on a dialog. I’ve added an option to save reliefs as STL files quickly rather than using the painful, and somewhat broken, polygon reduction code that I have now. I have the dialog below as a placeholder but the text is not good and I’m out of ideas. Any suggestions on how to label everything?
By Rob G. on Wed, Oct 21, 2009
I’m going to assume that few users are still using anything older than a Pentium 4/Celeron ( which were released in 2000) and make a few changes to MeshCAM. Starting with the P4, Intel/AMD made the SSE2 instructions available. Enabling them in Visual Studio gives MeshCAM a 6% boost in my test case without doing anything else. I expect that I can do better if I make changes to target these new instructions more explicitly.
By Rob G. on Sat, Oct 17, 2009
I had a case today, one one of the few times I get to use MeshCAM for a real project, where I had a metric STL file and I was using my normal Mach 3-Inch post processor. The intention all along had been that MeshCAM would have done the mm-to-inch conversion work without user intervention when saving the gcode. I was surprised when my mill tried to jog the X axis 185 inches to the right- this was obviously broken.
By Rob G. on Mon, Sep 21, 2009
I just uploaded the V3 build 5 beta to http://www.grzsoftware.com/dl . The primary fix here is the offset roughing crashes that were occurring. I can’t say for certain that the problem is gone for good but I have not been able to cause the problem to happen after I found the source of the problem.
By Rob G. on Sat, Sep 19, 2009
I think I found the bug that has been holding back my next release. Some users may have seen crashing when using certain models with the new offset roughing. The crashes were repeatable but would come and go as the machining parameters were changed. The problem was in the third-party library I’ve been using but it was my fault- I changed a parameter (a floating point epsilon for the programmers out there) with the intention of making everything more robust. I obviously failed and have now put the parameter value closer to where it should be. Since I didn’t write the code I have had to spend time to learn about its behavior when given the complicated real-world data that MeshCAM generates. Overall it has still been better than writing in on my own but it’s not as drag-and-drop as I would have liked.
By Rob G. on Tue, Sep 08, 2009
Two users, Jeff and Robert, have sent me files that, for different reasons, cause MeshCAM lots of trouble. This has caused me to dig into MeshCAM with a performance profiler and see what can be done. So far I’ve found a few spots that gave immediate increases with only a line or two of code changed. I cannot imagine how these changes can cause large improvements in speed but they have. I’m seeing 10-15% better performance for the finishing code.
By Rob G. on Tue, Aug 04, 2009
Over the years MeshCAM has been a test bed for different programming techniques and ideas. I try out lots of them and adopt the good ones more widely and drop the ones I don’t like. This is why you see frequent posts about small features requiring a large number of changes; this is always a good time to go back and get rid of the stuff that I didn’t need after all.
By Rob G. on Wed, Jul 29, 2009
Some have noticed that the forum was telling them they were banned permanently. This was a problem that popped up when I was upgrading to a new version and has been fixed. For anyone interested I would recommend against using phpbb for any forum. It makes simple things hard and hard things impossible.
By Rob G. on Tue, Jul 28, 2009
I just uploaded the first public V3 build. The V2 build doesn’t know about version numbers (I didn’t think far enough ahead) so it will not find the new build using the “Check for Updates.” Go to http://www.grzsoftware.com/dl and grab it there.
By Rob G. on Wed, Jul 08, 2009
I had a terrifying thing happen yesterday. I was testing the new roughing code and I found a bug in the offset code that generated a hard crash; unfortunately it was in a small piece of code that I licensed and is poorly documented. I think it was due to a piece of my code giving it a bad geometry outline but that doesn’t change the fact that it generated a hard crash that I couldn’t recover from or detect before it happened.
By Rob G. on Wed, Jul 01, 2009
The past few weeks have very productive and frustrating. The new roughing now working well and the offset algorithm has been very robust. Handling all of the special cases has taken most of the development time- every time I think I have it there’s a new special case the demands a partial rewrite. I think that most of those cases have now been taken care of and I can move forward to try and get it into a releasable state.
By Rob G. on Mon, Jun 08, 2009
I haven’t posted an update in a while so I thought it was about time. Long-time MeshCAM users may recognize the image below. It comes from my work a year or two ago to develop a good pocketing algorithm. At the time I was a little afraid of using it in production because pocket algorithms are notoriously difficult to get correct. After letting it stew in my head while working on my “more robust alternative” that I posted in the past few months I’ve come to believe that this code was probably pretty good. The “more robust alternative” suffered some limitations that could cause poor toolpaths if given data that contained the miniscule inaccuracies that floating point numbers can have. I figured that if I have to deal with that problem anyway I should use the “correct approach” that I had been pursuing before.
By Rob G. on Wed, May 13, 2009
As I started working on the new conformal roughing a bit more I realized that some fundamental changes would be required. Starting from a clean slate I wrote a new offset algorithm to base the roughing on. Long time readers may remember that I’ve had a spent some time working on other offset algorithms. My last one worked well but it wasn’t as fast as I’d like and it always had the potential to fail since it depended heavily on floating point math (even though it didn’t in my testing). My new code is much more robust and generates much smoother toolpaths than the old roughing even though the code is only half done. It’s still far from done but I think the proof-of-concept below shows enough promise to commit to this approach for V3.
By Rob G. on Fri, Feb 06, 2009
I have the roughing simulation code working pretty well and tested to the degree that I can so far. I’ve updated the display code to let the color of the toolpath vary depending on the feedrate so the new data can be visualized. Now I just have to redo the roughing code to take advantage of all of this.
By Rob G. on Tue, Jan 13, 2009
I just posted another build, 7250, to http://www.grzsoftware.com/files/MeshCAM-Setup.exe . There are is one bug fix, pointed out by Christian, where low-polygon models could gouge. This was a bug added during my optimizations a month or so ago and I did have to give up part of my speed gains to fix it. I haven’t benchmarked the update yet but I’ll do that in the next few days.
By Rob G. on Mon, Dec 29, 2008
I just uploaded another build to http://www.grzsoftware.com/files/MeshCAM-Setup.exe . It contains only one fix- Joe S. helped provide me with a file that demonstrated the rare “horizontal edge gouging problem” that has been lurking for a while. I was able to reduce the file to only two triangles that demonstrated the problem and find the bug. It was in an area deep within MeshCAM so I tried to limit the changes to the minimum required to make the problem go away. As it stands I believe the problem is gone but I may go back and reengineer some of this code for V3 to make it more robust.
By Rob G. on Fri, Dec 26, 2008
I just uploaded a new build that fixes the crashing that could appear when calculating the toolpaths for image geometries. I’m not sure when this bug got put in there but it should have been evident for quite a while. I had a user, John K., that put some heavy duty debugging work in to help me find it. It ended up be due to the multithreading try to read and write the same memory locations at the same time. Rookie mistake.
By Rob G. on Tue, Dec 23, 2008
I just uploaded the latest build to: http://www.grzsoftware.com/files/MeshCAM-Setup.exe . It will also be detected by the “Check for Updates” command. There are a small handful of changes and two big ones- the ZMap memory reduction and the finish pass speedup. I really hope to make this the LAST release before calling V2 done so if no big bugs are found then this is it. As always, let me know what you think.
By Rob G. on Thu, Dec 18, 2008
My initial attempt to eliminate the ZMap failed pretty badly- the offset time tripled. This was mainly due to the offset being calculated to the accuracy of the finish passes. Although this represents a big improvement in accuracy, since the ZMap is currently calculated at a lower resolution than the finish pass, it’s probably totally unneeded. I did some testing to see if I could do some type of hybrid approach and the results were promising. Unfortunately, it will be too big a change to add right now so the final ZMap elimination will be deferred until V3.
By Rob G. on Thu, Dec 04, 2008
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.
By Rob G. on Mon, Nov 24, 2008
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.
By Rob G. on Thu, Nov 20, 2008
I just uploaded MeshCAM 7151 to www.grzsoftware.com/files/MeshCAM-Setup.exe . You will not find it in the check for updates feature of the last few versions because I only want people to try the latest after reading this message. This is a transition release as I wrap up V2 and begin V3. I made a number of SIGNIFICANT changes including a new installer and the app is now compiled in Unicode to support multiple languages. Win98 is now unsupported, even though it was never explicitly supported, since Unicode is not available there. I made literally thousands of changes to make this possible and I’ve been using it in my shop without errors. There are a good handful of other fixes as well. I will be curious to hear what your feedback is. Please tell me if this one worked or didn’t for you.
By Rob G. on Thu, Nov 13, 2008
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.
By Rob G. on Tue, Jun 03, 2008
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.
By Rob G. on Sat, May 24, 2008
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.
By Rob G. on Mon, May 19, 2008
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).
By Rob G. on Wed, Apr 30, 2008
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.
By Rob G. on Fri, Apr 25, 2008
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.
By Rob G. on Wed, Apr 23, 2008
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.
By Rob G. on Thu, Apr 03, 2008
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.
By Rob G. on Tue, Apr 01, 2008
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.
By Rob G. on Sun, Mar 30, 2008
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.
By Rob G. on Thu, Mar 27, 2008
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.
By Rob G. on Wed, Mar 26, 2008
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.
By Rob G. on Thu, Mar 20, 2008
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.
By Rob G. on Wed, Mar 19, 2008
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.
By Rob G. on Mon, Mar 10, 2008
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.
By Rob G. on Sat, Feb 23, 2008
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.
By Rob G. on Fri, Feb 15, 2008
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:
By Rob G. on Wed, Feb 13, 2008
Below is a shot of the new changes to the finishing toolpaths. The paths are now projected down onto the geometry and properly subdivided . You can see how the supports are avoided and that a minimum amount of stock (and no air) is cut- a big improvement from before. I have the “Don’t Machine Top of Stock” working and I now need to make the threshold angle work properly. I’ve got some ideas about how to improve that while I’m updating the code. Until now I had been calculating the angle of the toolpath or the offset surface. I’ve been playing with the competition and they seem to use the original surface as the reference angle. I had tried this before but made some bad mistakes that kept it from being reliable. I’ve come up with some new ideas that should make it work much better and, hopefully, faster.
By Rob G. on Mon, Feb 11, 2008
I’ve come to a stumbling point on the latest toolpath updates as I try to come up with a simple way to eliminate some of the unneeded retracting on finish paths. I’ve got a number of ways to approach the problem but none that I believe will work quickly and without a lot of bugs over the following several months. I finally put the problem aside for a few days since I wasn’t making a lot of progress. I decided to try adding multithreading support since I use a dual-core laptop and the new toolpath engine that was introduced over the last year is well suited to parallelism (I planned ahead for a change).
By Rob G. on Fri, Jan 04, 2008
I got the basics of the machining margin code working. Below you can see the roughing limited to .25” around the standard MeshCAM model. This should make 2-side machining, and machining using supports, much more attractive. No longer do you have to define the border size either, the supports run to the edge and you just define how far beyond the model to machine.
By Rob G. on Wed, Dec 12, 2007
I’ve got most of the new geometry support code working and it’s much better than before. First, the way that each position is selected is much more robust; you should no longer have any trouble placing them where you need them. You can also see that they have a new shape in the pictures below, they’re now elliptical. Each point on the ellipse is intersected with the model to ensure an accurate fit. This means that you should not have any gaps at the edges of the support if it meets a curved surface and, if you’ve got a thin walled part, you should never have the support break through to the interior. The elliptical shape keeps the perimeter of the support closer to its center which should reduce the likelihood of part of the support missing the geometry. The new code can handle a miss but it will always be better to avoid the problem in the first place. Purists may not like the new shape because it’s got a smaller cross section and, as a result, will be less strong. The new code I mentioned a few days ago about only machining one tool diameter away from the geometry in the future, as opposed to clearing the whole area as it does now, will keep the effective length of the supports shorter. I think this will more than offset the reduced cross section.
By Rob G. on Sat, Dec 08, 2007
The next thing in the list to be updated is the code for adding supports to the geometry. I didn’t know how many people were using them until recently so they had not received much attention. I spent some time redoing part of the code to make them applicable to any type of machine job- not just 2-side jobs. The support changes probably won’t take too long but it dovetails into some other changes I wanted to make to optimize the machining regions. I’m going to try adding a way to machine only the area covered by the model + the tool diameter- not just the bounding area but a free-form polygon that would be automatically calculated. This eliminates the need to define the frame dimensions for 2-side jobs. In theory this should not take that long but who knows.
By Rob G. on Wed, Dec 05, 2007
I just uploaded Build 6738 to http://www.grzsoftware.com/files/MeshCAM2-6738.exe . I’m posting it here only until I get some feedback to make sure I didn’t break anything.
By Rob G. on Sat, Dec 01, 2007
Below is a screenshot of the first mockup of the new stock dialog. It’s far from done, it’s ugly, and a few buttons, like “Center Geometry in Stock”, have not been included. The reason I have posted it here is to get input. I was attempting to give the user a lot of flexibility compared to the current dialog but now that I look at it it seems like it may be overkill. I’m not sure that it’s necessary to define each margin around the geometry separately. Some competitors don’t offer this. Your thoughts are appreciated…
By Rob G. on Thu, Nov 01, 2007
Looking at the competition I’ve come to the realization that it’s changed in the last 3-4 years. When MeshCAM was started the existing programs were pretty ugly and didn’t work too well, or at least they weren’t actively in development. Now that others have joined the market it’s time to review the status of MeshCAM. For the money it’s probably the most full-featured product available but it doesn’t compare as well in the attractiveness category. I’ve started adding a new menu interface following the now common “left-panel interface.” I’ve got it working and I’ve already gotten used to having the commands available without using the menus.
By Rob G. on Sat, Oct 20, 2007
Several people mentioned problems with 6701 toolpaths but Klaus was the first to send me an STL file that let me replicate the error. It was a bad bug where some triangles could be totally ignored when using a flat endmill. A new version is being uploaded now that has a fix and adds the slicing back in. Slicing is not totally done but it’s in the build already and I need to post it now to get rid of the bug above. Since it’s a public release you can get it at http://www.grzsoftware.com/dl .
By Rob G. on Fri, Oct 05, 2007
If you’ve been following the support group you’ve see that there’s been a lot of discussion about adding the slicing mode that was in version 1.18. I removed it in V2 with the intention of adding it back in but never got around to it. Yesterday I began writing code for the new slicing mode and came across the old disabled command from 1.18. I reenabled it and, to my surprise, it worked well. The old dialog did not support mm and inch input so I had to fix that. The images were not up to my current standards so I redid those as well. If my testing goes well it could be released within a week or so.
By Rob G. on Sun, Sep 30, 2007
Jay H. pointed out a bug in the latest releases where the geometry supports are ignored when a toolpath is calculated. I fixed that and posted a new release at http://www.grzsoftware.com/files/MeshCAM2-6701.exe . Try it out and let me know how it works.
By Rob G. on Sat, Sep 22, 2007
Jeff D. was the first to point out a significant bug in the latest releases. It turns out that the finish path could gouge if the roughing tool was much bigger than the finishing tool. This was due to a bug in one of my optimizations and has been fixed in 6699 at http://www.grzsoftware.com/files/MeshCAM2-6699.exe . Build 6699 has a few other little fixes and tweaks in addition to the big bug above. I also added Lua scripting access to modify some of the internal machining parameters for the real tweakers out there. I’ll try to post a Lua script in the next few days that will describe the parameters and show how to modify them.
By Rob G. on Mon, Sep 17, 2007
OK- the testing went better than I thought so I’m posting a new release here for everyone here to try out. There’s still some improvements to be made for the pencil and waterline paths but in all of the testing I’ve done over the past few weeks of development it seems much better than any of the previous releases. Let me know how it works.
By Rob G. on Fri, Sep 14, 2007
In the past people have requested a way to have the finishing toolpath ignore the top of the stock if it’s just going to try and machine it flat. This would be a great option if you’re trying to machine a mold or something similar where your stock is already machined on the top face. When I redid the code for the parallel finish I made sure to add support for this feature. I planned on waiting to add this option to the dialog since it would require modifying the code for the dialog- never a fun thing to do. I ended up having to do this anyway for the new toolpaths options so I went ahead and enabled the new feature, “Don’t machine Top of Stock.” Below is a shot of the new option to look for and the results.
By Rob G. on Fri, Sep 14, 2007
The pencil algorithm is starting to work well now. Simple paths are no problem as shown by the star shot below. To get paths with some potential ambiguity, like the standard “Cheese Whiz” model, to work I’m going to need some more code and testing.
By Rob G. on Wed, Sep 12, 2007
The bulk of my time has been spent on trying to get a good toolpath coverage when both waterline and parallel finishing are being used. This turned out to be difficult to calculate quickly and accurately- the two characteristics always oppose one another. After trying about six different approaches I think I’ve got a good approach. The photo below shows the current status. You’ll see that there is some overlap between the two but there is very little “spiking” near the threshold like the previous versions.
By Rob G. on Mon, Sep 10, 2007
After the last posting it took about a hour to move the new waterline code from the test command in the photo into the main machining dialog. It worked pretty well until I started playing with the machining angle- I found the parallel and waterline were not consistent near the threshold angle. I’ve tried a number of approaches and am finally closing in on a good solution. My current approach may have more overlap between the regions but with fewer retracts and a much smoother finished part because I’m trying to maximize the path length rather than stopping a path when a surface angle threshold is passed- even if it’s only exceeded for a short span.
By Rob G. on Mon, Aug 27, 2007
Randy sent me a photo of a toolpath showing a defect where the parallel finishing path would undercut when the path was almost but not quite right. I was able to fix it quickly but the fix led to a 25% increase in calculation time and I didn’t want to go backwards on that after all of the optimizing effort. I wrote a new subdivision method that eliminates the problem with a slight penalty in calculation time. After I spend time optimizing it I expect the get an overall speedup because it allows much more targeted and intelligent subdivision than the initial one.
By Rob G. on Tue, Aug 21, 2007
I just uploaded a private release at http://www.grzsoftware.com/files/MeshCAM2-6628.exe . It has the new and improved parallel finishing code that should be nearly done- unless bugs are found. I have not been able to duplicate the waterline bugs that were sent to me but there does seem to be a new bug that adds a bunch of retracts. I’m not too worried because the waterline and pencil finish will be rewritten soon anyway. I may do waterline before pencil because of this bug.
By Rob G. on Sun, Aug 19, 2007
Below is a side by side of a toolpath using the Jeff Demand Reference Model. The total area of the shots is probably a couple of mm so the details you’re looking at are very small. Both are using the same tolerance value, .025mm or about .001”. Obviously, the paths are much better in the latest code. The main change is that I reduced the amount of point reduction in the toolpaths relative to the tolerance value so that the gains from the new toolpath code are not thrown away at the very end. For an equal tolerance value the next release will generate a larger gcode file.
By Rob G. on Fri, Aug 17, 2007
Over the past few hours I’ve been trying to get to the bottom of what takes so long in the new code. Specifically, the Jeff D reference model has been enlightening as I’ve reviewed the reams of data generated during a toolpath calculation. Given the hugely dense model, it turned out that I needed a way to make many of the triangles go away if I wanted to speed it up. I was able to come up with a final optimization that removed a lot of triangles without reducing accuracy in any significant way ( I won’t go into details but it’s not obvious). In Jeff’s model this led to a reduction of about 30% in the triangle count. Also, I tweaked all of the variables that define how much to reduce the points in a toolpath and when to subdivide the path. The bottom line is that I’ve reduced the toolpath calculation time from a starting point a week ago of something like 3000 seconds to 576 seconds. Additionally, the toolpaths look much better when viewed close up. With Jeff’s permission I’ll post a few photos.
By Rob G. on Thu, Aug 16, 2007
I just finished testing today’s optimizations on the “Jeff Demand Reference Model.” Jeff sent me a 27MB STL file with >500k triangles over a very small area about 60mm x 20mm. With the parameters that he initially provided the toolpath calculation time was over 3000 seconds- obviously way too much. After a lot of optimizing I’ve gotten it to about 1200 seconds (about 20 minutes). It’s still too much but it’s a great improvement and if I can cut it in half again then I’d be happy. Once I get everything as tight as I can then I can enable multitreading to take advantage of the multicore CPUs that everyone has not. The ZMap-based code did not lend itself to multithreading but the new code is perfect for it.
By Rob G. on Mon, Aug 13, 2007
Thanks for all the feedback over the last week about the 6512 test release. I’ve managed to speed up the calculation by almost 50% for very large models but that still leaves them running for quite a while. I’ve made some major changes but I think I’ve still got a lot of possibility left. I hope to have another release in the next week.
By Rob G. on Sat, Aug 11, 2007
I just posted a test release of the new version at www.grzsoftware.com/files/MeshCAM2-6512.exe . I’ve spent the last half a day in a hotel room finishing everything up to the point that I believe it works will and decided that I have several users who would probably like to participate in the test process. Please run it through the wringer and let me know what you think. Here are some important notes:
By Rob G. on Sat, Aug 04, 2007
Below is a shot of the almost-working finishing code. The big thing pictured below is that the threshold angle is now working (set to 20 degrees below)- I forgot that I would need to know the angle of contact with the cutter to determine the angle for both parallel and waterline finishing. This took another bunch of code and testing to get done. Also, the path linker turned out to be inadequate for the task and required a lot of changes to reduce the unneeded retracts. Luckily I’ve rewritten that so many times that it went really quickly.
By Rob G. on Tue, Jul 31, 2007
As I mentioned before, I’ve been rewriting the finishing code to eliminate the ZMap. The ZMap has several problems, the first is that a highly accurate toolpath requires a ton of memory. A second is that it you have to do a lot of calculations on the area in between raster lines that you don’t really care about other than avoiding collisions. Finally, since you’re evaluating the toolpath on a rectangular grid you cannot dedicate more memory/processing to the more detailed areas; it must all be uniform. The benefit is that it’s fast if you use a lot of optimizations and it’s bulletproof.
By Rob G. on Mon, Jul 16, 2007
I finally got the new code for filleted end mills working. I tried a number of ways to solve the line/torus intersection problem including one from an academic paper that seemed to just not work. I had hoped to solve the equations analytically but the math becomes unwieldy and round off errors due to floating point calculations make an iterative solution more accurate anyway. Below you can see an example of all of the work. It doesn’t look much different from a current toolpath and that’s a good thing. One difference though- this one takes every triangle in to account at each step. The current zmap-based approach can miss tiny features that fall between sampling points.
By Rob G. on Thu, Jul 12, 2007
I’ve been working on the new offsetting code to make smoother and more accurate ZMap-free toolpaths. Eventually this will be carried to all toolpaths but it will first appear in the finishing since that would be the place where more accuracy will be appreciated. It will take longer to calculate the new paths than the current ones but they will be something that can eventually be distributed between multiple processors since most new computers have multiple processors or cores. The new code is very math intensive and, in order to speed it up to a tolerable level, each type of cutter must be implemented separately. This leads to many cases to test and long hours of debugging.
By Rob G. on Thu, May 31, 2007
As you’ve noticed, I uploaded the new website. I forgot to check it against IE6 before doing so and there were several things that displayed wrong. I think I’ve found most of them, aside from some more minor not-quite-centered problems, but if you seen anything really wrong then please let me know.
By Rob G. on Mon, May 21, 2007
I just uploaded a new version that fixes a new bug I found. Under certain circumstances the finish stepover may be wrong depending on the oversampling value. This got introduced in the last couple of releases and I’m shocked that nobody reported it.
By Rob G. on Wed, May 16, 2007
I haven’t heard of any big problems with the new roughing algorithm so I’m going to make it a public release in a few days. Tonight I was able to add code to notify a user if a post processor doesn’t support 4-axis when it’s required. I think this may be the root of some of the 4-axis problems that have been reported.
By Rob G. on Wed, May 02, 2007
I just uploaded build 5934 to http://www.grzsoftware.com/files/MeshCAM2-5934.exe . It will not appear on the main download page since the roughing code is still relatively untested. Please send me your feedback so I can address any problems.
By Rob G. on Wed, Mar 21, 2007
I just finished a recompile of the new roughing code integrated with the existing waterline code and it seems much more stable against several of the bugs that people pointed out. There is still potential for problems but I haven’t found anything but some unneeded retracts. Once I get the code tested by a wider audience I’ll try to track down the extra retracts.
By Rob G. on Tue, Mar 20, 2007
I just posted build 5681 to www.grzsoftware.com/files/MeshCAM2-5861.exe . It will not appear on the normal download page until I get some feedback since there are big changes due to the new roughing algorithm. Please provide feedback as you test it.
By Rob G. on Sun, Mar 11, 2007
As I was going through all of the code to make the new roughing algorithm work I figured now was a good time to remove the problem of redundant offsets if two passes, like a parallel finish and a pencil pass, use the same tool. It was a deeper change than I anticipated so everyone will need to keep an eye out in the next release for quirks.
By Rob G. on Sat, Mar 03, 2007
There was a problem on the new site here where IE6 didn’t show a “Submit” button when you were ready to post a comment. I found the code, CSS again, and removed it so the problem seems fixed. Sorry to those who tried to comment but couldn’t.
By Rob G. on Fri, Feb 16, 2007
I was told by a user that this new page rendered wrong in their browser. I hadn’t had any problems on Firefox2 and IE7 but when I loaded an old VMWare image with IE6 I was able to get the page to sow in IE6 in a readable way. I haven’t had time to track down the offending CSS problem but I at least found a way to get the page to display.
By Rob G. on Wed, Feb 14, 2007
The next release of MeshCAM will drop the “Work-in-Progress” label and become MeshCAM 2 Build XXXX. I don’t think V2 will ever be labeled “Done” until I move up to MeshCAM 3 because I’m about to make a big change that will hurt the stability. The current MeshCAM codebase is pretty stable and all of the changes for the next few months should not risk a drop in stability.
By Rob G. on Fri, Feb 09, 2007