Build 6689
September 14, 2007 · Filed Under MeshCAM Development
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.
http://www.grzsoftware.com/files/MeshCAM2-6689.exe
Comments
10 Responses to “Build 6689”
What a great build, Robert! The waterlining, at least on my “standard test piece” has no castellations at all. Brilliant! My only comment, now that I am actually trying waterlining, is that the waterlining is unidirectional (clockwise around a convex surface on my part.) When the waterlines do not make a full circumnavigation of the part, the Meshcam traces one waterline, then retracts to safe height, traverses to the starting point of the next waterline, plunges and then traces the next. Would it be possible at all to do the waterlines bidirectional, like the X or Y rasters, so it will move directly to the nearest end of the next waterline? Or is that something that would be impractical gouge-prevention-wise?
My other very slight comment is that the roughing quality only goes to 15. You had mentioned that it was going to go to 20 (or maybe 21 for fanatics like me.)
Did you reconsider that?
But so far, I would be very very happy for this to be the next release. You’ve outdone yourself, Robert.
Oh wait, I haven’t tried penciling. Another comment in an hour or two…
Best regards,
Randy
Glad you like it and sorry your posts got marked as spam. You’d never believe it but there are probably 50-100 spam comments a day and you somehow got flagged.
Currently I have waterline set to machine complete z level slices at a time rather than depth first. This is both easier to program reliably and if there is a bug it’s less likely to gouge. Changing that now would be a significant addition but the time savings during machining will justify it eventually. It’s too big a job for right now though.
I did increase the roughing quality internally. Roughing requires a minimum of 4 so I add 4 to whatever you select and use that (giving a new range of 4-19). I can increase it more but I’m afraid that people will automatically select the best even if they don’t need it. In some cases this could be a lot of memory used. If you really really want it higher then I’ll move the range up a few more steps.
-Robert
Hi Robert
Very nice!
Liked the speed, and generly liked the overall feel.
I have a problem with the don’t machine top surface selection though, on the few parts I tried parallel finishing always did the top. I tried it with “machine geometry only selected and deselected.
I’ll get a chance to try a few other parts tonight so I’ll see if it’s all or just some parts. Admitedly most of my parts require full machining.
Steve
Robert,
Nice speed but I’m getting almost random little clusters of gouging.
Example screen shots of finish pass, geometry, .stl, and tool selection at
The finish tool is an tapered 18 degree included ball. Sample part is about 6mm and slightly angled with respect to XY plane.
The last build to not show this was 5946.
I look forwards to playing with the improved waterline strategy but not at this price
Jeff
Steve- can you send me a screenshot of the Don’t Machine Top failure?
Jeff- Come on… is a little gouging really that bad? Send me the link- the blog software strips links out of the posts so they don’t make it in the comment.
Uh-oh. I got a gouge on one of my trials, went back and looked in Cutviewer in detail at that area and sure enough it was there too. Went back to MeshCAM to play with parameters and could not reproduce it (even going back to the same parameters later.) I sing;e-stepped through the gcode after I roughly found the area, and it was shortly into the parallel X pass, after the waterlining.
Best regards,
Randy
P.S. I’ve just gotten a new project–a 1:20.3 scale steam locomotive wheel, about 3.5″ diameter. The STL is 104MB (I am just starting to play with tolerance settings in creating the STL from the solid file given me) but it does not crash MeshCAM. Takes a whole long while to slog through the file, and I need to restart MeshCAM after each toolpath output, but MeshCAM is holding up well with the ginormous file!
Randy-
What size tool did you have when the gouge occurred? I had a hypothesis about the cause for Jeff being due to his tiny tools but you usually use a larger too right?
Take lots of pictures of that wheel if you can- I’d love to have some to post.
-Robert
Robert, I was using a .250″ ball-end for both roughing and finishing (lazy me!) I was using .020″ stepover for X finishing and .020″ stepdown for waterline.
I have a screenshot from CutViewer that shows the move that caused the gouge, and a screenshot from 3 moves later. I’ve been strobing them and see what happened. The end of one X raster was fairly low in Z, but the surface stepped up considerably before the next X raster line. The offending move is diagonally up from the end of the one to the beginning of the other, where properly it should have raised Z to the level of the next, then stepped over in Y. I’ll send you the two screen shots.
Best regards,
Randy
P.S. And yes, I will definitely send photos of the wheel.
Robert, I was using a .250″ ball-end for both roughing and finishing (lazy me!) .020″ stepover on the X finishing, and .020″ stepdown on waterline.
I have a screenshot from CutViewer that shows the offending move, and another screenshot 3 moves later. Meshcam had just finished an X pass on a downward-sloped surface that ended low in Z. Before the next X pass (.020″ over in Y) the surface stepped up to a much higher Z, so that the next X pass had to start correspondingly higher. Rather than moving up in Z to the new height and then over in Y, Meshcam just moved diagonally straight to the next point.
I don’t know if it is a factor that my stl file has an undercut below the higher surface rather than a solid vertical wall.
I’ll send you the screenshots. And definitely I will send you photos of the wheel. I have some toolpath tweaking to do–the latest test gcode file is almost 13 megs and would take 11-1/2 hours to machine at 20 in/min…
Best regards,
Randy
I just took a look at the files- that’s pretty weird. I’ll dig into it. What tolerance value were you using?