Request for Comments- Retract Height
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.
One of these old chunks of code is the retract height code. You will notice that once you pick a reference point; the geometry, the stock, or the program zero, the retract plane will always track the changes to that reference. This flexibility seemed like a good idea at the time but now, for a number of architectural reasons, should probably be removed if it isn’t being used. In the last 5 years I have only used the top of stock as the reference and I suspect that 99% of users have done the same. Can anyone provide a good situation where the other two options would be required?
V3 Updates and Forum Trouble
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.
I have been working on the ability to save jobs for a few days. So far so good but it required many more changes than I ever anticipated. I had an architecture where a new file would trigger little bits of code to fire off all over the program to set the stock, zero, etc. because I never planned on all of that to be loaded with the geometry. It took a few days to find all of the little bits of code that interact and eliminate them. It seemed like a good idea 4 or 5 years ago.
The streamlining of code is great- I think it will be a big benefit moving forward. The new .MCF file handlers are about 90% done so I’m probably about a week or two from release. I have a few reported bugs to dig into before that point.
I also added the ability to drag files into the wind to open them. This should have been about 20 lines of code but it took half a day to make work. It turns out that drag and drop will fail in Vista and Windows 7 if you drag from a normal permission window (Windows Explorer) to an administrator window (MeshCAM running under Visual Studio). It fails silently so it just appears to be broken. It’s probably good to torture programmers with this type of thing so they remain sympathetic to their users.
Version 3 Build 4
I just uploaded a new version of the V3 beta to http://www.grzsoftware.com/v2dl.php . If you have V3 already the Check for Updates will find the new version.
This is not a major release, just a handful of changes to polish a few of the rough edges. The only one you need to know about ahead of time is the icon placement. Randy mentioned that the icon was in the root of the start menu rather than in the programs directory. This bug got introduced when I changes installers a few months ago and I didn’t notice. The new installer will put it it in the right location but you’ll have to uninstall the current version to remove the icon that is there now. Not a big deal but be sure to do it if the icon placement has been bothering you.
The next big update should add the ability to save MeshCAM files with the geometry, stock, supports, etc. in one file. This is about 30% done and I don’t think it will be a real difficult one to complete.
MeshCAM V3 Build 3 is Ready!
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/v2dl.php and grab it there.
I made some UI changes like removing the log window and locking the side panel. Some will not like this but it will become important as I begin to move more the UI from separate dialog windows to the dock on the left.
I increased the toolpath accuracy thresholds somewhat since it helps the roughing. This slows down the toolpath code slightly but I figure that computers have gotten a bunch faster since that toolpath code was introduced and this will be used for the next few years so it’s worth bumping it up cash in on that extra CPU performance.
Some of the vertical jags showed back up in the roughing and I realized that some of this is due to the nature of the 3D roughing. Since it is looking at a “thick slice” of the geometry it can catch the edge of the geometry and cause the tool to lift. There are a few that are not geometry-related that I need to spend more time on.
Let me know how it works for you.
UPDATE: Jeff just pointed out that I forgot to mention that V3 keeps the data it needs in a different registry key than V2. This was done to allow you to keep V2 and V3 both without interference. Because of this you will have to reenter your registration code in V3 the first time you use it.
Last Minute Roughing Change
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.
Out of fear of future trouble I decided to change to my parallel pocket code that’s used in the parallel finishing toolpath. This also choked on the bad data but only gave me a bad toolpath instead of a crash. While not good this is always preferable to a crash. The parallel code also helped me find the flaw in my code that generated the bad outline.
The good thing is that the parallel code is much faster- up to about 10 times faster. So here’s where I stand: I am always afraid of offset pocket algorithms and they’re relatively slow but I’ve invested a lot of time in this one and it has never failed when given good data…. and pride won’t let me drop it. The contour offset and parallel algorithms are almost drop-in compatible so I’m going to include both and let the user pick which one. Both will support the “3D Roughing” previously referred to as “Contour Roughing.”
I also fixed the bad vertical spikes. The paths look very nice now.
