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.
Comments
12 Responses to “Build 6908”
That’s OK, Robert. I can just blacklist MC in my firewall like all the other programs that want to “call home.”
Nothing personal but I like control over my tools.
Randy
Robert,
Now you have managed to paint your self into a corner. We need another new release to properly test the “Phone Home”
No comments yet on the new pencil and waterline, but I don’t often use/need them. At least no crashes nor smoke pouring out of the computer so far.
I can understand not posting new version info here but until the new checking feature is well tested it’s probably a good idea for a while. And I do really enjoy your thoughts and notes on progress.
Jeff
Robert,
I’m getting gouging on the parallel portion of mixed parallel-waterline finishing on that model I recently sent you. I have a 45-degree cutoff for the waterline. Calculating parallel alone with a 45-degree cutoff is OK, as is waterline alone with the same cutoff, but mixed gives the problem. I’m trying to document it with screenshots to send you along with the “offending” gcode.
I’ve also noticed that 6908 seems to be much more CPU-hungry than the last version or two. It’s back to virtually locking up the PC during the toolpath generation, to the point of not being able to call up Task Manager…
Randy
Randy-
Send me whatever docs you can- I haven’t seen any gouging yet but I’ll keep looking.
There is a change to the process priority when calculating the toolpaths; MeshCAM should automatically drop to “below normal” priority until the calculation is finished. My best test comes from playing an MP3 while running MeshCAM. I no longer get even a hiccup in the audio playback during the toolpath calculation. This was not true of the last release where I was playing with thread priority but leaving the main MeshCAM process priority as normal. I imagine that there could be some system-specific quirks here as well. What OS and CPU are you running?
-Robert
Robert,
I’m running XP Pro SP2 on a 3GHz P4 Prescott with 3GB RAM. I will try playing an MP3 the next time I do a toolpath and let you know. Maybe you should build that in. [ducking and running]
I must say that 6908 feels really fast on the toolpath generation. I’m using .0005 tolerance now on my locomotive wheel with a .005 stepover, and getting X-Y parallel toolpaths in about 1200 seconds calculation time. That is almost twice as fast as I was getting with 6903 with .001 tolerance if I can read my scribbled notes correctly.
Randy
Robert,
No, I was wrong. It is over 3 times as fast on my workpiece! On .001 tolerance and .005 X-Y stepover, I was getting about 4000 seconds. (Found another scribbled note–have I ever mentioned that it would be very helpful to dump the toolpath generation parameters into comments in the gcode file? To me that would be much more useful than any toolpath improvements right now!)
Randy
Robert,
A strong second on including the parameters as a comment in the g-code file. Best place (at least for folks running old DOS controllers with a very limited view of the code) would be at the bottom of the Start = **** of the post just before the actual program start. I put basic machine configuration and setup numbers in the first few comment lines, really useful when running an old file.
Keeping track of all those little scraps of paper notes is not fun, too much required timely manual editing even for quick tests, something dumb computers are really good at.
Jeff
Robert,
MP3 played fine. It took a little searching to find a long enough one…
But what suffers is anything that involves user interaction with Windows–bringing another window to the foreground, opening a new tab in Firefox, etc. Stuff that is not very CPU-intensive but requires handling the mouse or keyboard. Or so it seems to me.
With the excellent state of roughing and parallel finishing, I’m a happy camper with the toolpaths right now.
Randy
Performance of 6908 appears to be much better. My roommate and I just bought mesh cam art last night(my trial expired…) I would very much like to make a request. I would like the Max surface angle in the parallel finish section to determine the max surface angle that the parallel finish will machine. E.g. any surface parallel to the table would be a surface angle of zero, perpendicular would be 90. So if i specify a max surface angle between zero and one, I would like it to only machine surfaces parallel or “near” parallel to the table. If i were to specify 90 or greater I would like it to machine everything. I consider this request to be critical. Please let me know if and when this can be accomplished.
Daniel,
It already works that way, except 0 is vertical and 90 is horizontal. If I specify 88 degrees, only nearly horizontal surfaces will be machined.
BUT, in my experience any surfaces between two horizontal surfaces that are at different levels, will also be machined. I think that’s just the way Meshcam works.
I think I’ve said this before, but if I really don’t want certain surfaces machined I will add “safety stock” to them in a second copy of the solid model and use that one to “target” only the surfaces I want touched.
You are right about the speed, though. I’m using .0001″ tolerance on all my models now (I don’t do anything larger than 5 or 6 inches across) since it doesn’t seem to have any speed penalty vs. .0005″ tolerance, if the elapsed time display in the status window is correct.
Best regards,
Randy
Randy/Daniel -
Actually, you should not have to flip the values as Randy suggested but your post did make me go back and look and, sure enough, something seems broken. I’ll look at it in more detail and fix it.
Part of the confusion is that 0 and 90 are both ways to tell MeshCAM to machine everything. This was a very bad idea that I did a long time ago when, to my warped programmers mind, it didn’t seem that bad. Your post also reminded me that I wanted to fix that before my next release.
-Robert
Robert,
I didn’t think so either, but I made a couple of quick trial runs on my favorite (current) STL to verify.
Randy