Out of Touch for a Few Days
I just wanted to post a warning that I’ll be travelling until the 31st and may be without Internet access for part of that time. If you place an order or email me then my responses may be delayed for a little while. Sorry for the trouble.
V4 – New Slice Command
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.
There is only one problem- parts with undercuts look funky. I am taking some geometric shortcuts to generate the slices that make the system as robust as possible. Undercuts end up with big planes above them that, while technically correct for a 3-axis mill, are ugly. I’ll be curious to get feedback on that part after release. I’d post a photo of that but I’m in the middle of a rebuild and the blog post gives me something to do while waiting.
Version 3 Done, Version 4 Started
I was planning on taking a month or two off after finishing V3 but I ended up jumping right into V4 later in the day. I’ve managed to get the following items done so far:
- Changed to a new version of my threading library
- Made waterline toolpath direction consistent- currently climb milling
- Added timeout to beta releases
- Added "Append as Check Surface" to file menu
- Draw supports in red
- Added busy dialog when saving job
- Changed source control system
So far the todo list contains another 32 items to get done before release. A few of those are internal and will never be seen by users but the rest should be pretty good.
The current plan is to try and complete V4 as quickly as possible and not let it linger for another year like V3 did. I hope to have the first work-in-progress out in the next month or two. The betas will have a timer to run for 60 or 90 days so they don’t end up out in the world forever. The work-in-progress releases will function with current license codes but the final V4 release will be a paid upgrade. The cost will be minimal and anyone who purchases from today forward will get a free upgrade. I’ll probably backdate that a month or so just to make sure no one feels cheated.
I’ll share more of the todo list when I get my priorities worked out. Until then, let me know if you have any pet features you’d like to see in V4. I can’t promise that they will make it into the final product but I promise that all requests will be considered.
Say Goodbye to V2
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.
Build 17
I just uploaded V3 Build 17 to the normal spot, http://www.grzsoftware.com/v2dl.php . 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.
I also moved the tools.txt file from the Program Files to the Local Settings directory to avoid Windows 7 security problems. It should be automatically moved the first time you run MeshCAM. If you’ve been building that tool file for years then it would be worth backing it up before running this build just to be safe.
Let me know what you think.
V3 Build 16
I just uploaded build 16 to http://www.grzsoftware.com/v2dl.php . 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.
Explaining the Roughing Spikes
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.
When the roughing toolpaths are laid out, they are done in 2D first and then projected down to the surface. This process includes the contours being adjusted and moved several times along the way. As I’ve mentioned it here before, floating point numbers pickup errors as they are manipulated.
Since the inner and outer contours of a pocket started out being in contact with the surface, you would hope that they would remain in contact when you’re done. If the point has moved in the XY plane then the point would now undercut or overcut the model in some microscopic way if the Z value remained the same. If the points were not projected back down then you would never know about it- the over/undercut is way beyond the capability of your machine anyway.
If the shifted point happens to fall on a surface with a very steep slope then even a very small shift in XY distance will cause a large shift in Z. The picture below shows this effect.
The solution here will probably be to lock the Z value of the contours that are in contact with the model. I am going to try a few more things before that but I’m at a loss to come up with a better solution right now.
For what it’s worth, I was able to determine that one of my methods to fix the problem, that has been shipping for a while, actually made the problem worse.
In the mean time just remember that they are ugly looking but are not gouges- they should never be visible on the final part.
V3 Build 15
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.
Version 3 Build 14
I just uploaded build 14 to http://www.grzsoftware.com/v2dl.php . 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.
The roughing code has the big changes I outlined in the past couple of weeks. I think it’s solid and I’ve got tons of units tests that run every time I run a debug build so that expectation is backed up by lots of data (as long as I considered every case). Let me know if you find anything and if you have the time, try running a few of your typical parts with a “Machine Geometry +” set to zero.
Finally, for Jeff, I remembered to rename the installer so that it includes the build number. If I forget to do this in the future please let me know- eventually I’ll be able to make it part of the upload habit.
Roughing Fixes Appear to Work
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.
