ZMap Elimination
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.
If it works then I’ll put out a release with the speedups pretty soon. I haven’t gotten any show stopping feedback about the last beta so I think I’m in good shape.
Comments
17 Responses to “ZMap Elimination”
Robert, it’s not a show-stopper by any means, but the “machine geometry plus” overrun is bothering to me because it causes me to make the rawstock bigger than it would need to ideally be.
http://www.prototrains.com/misc/margin2.jpg is the latest example. MeshCAM-generated supports, 0.250″ ball mill used for both roughing and finishing, “machine geometry plus” value of 0.300″ To me that means that the centerline of the cutter should not get more than (.300-(.250/2))= .175″ from the edge of the part. The toolpaths (I hid the roughing to make the picture clearer) show the centerline of the cutter going at least a full diameter away from the part. Am I misinterpreting the “machine geometry plus” parameter?
Thanks,
Randy
Ahh, this goes back to one of the early MeshCAM controversies. All measurements are relative to the center of the tool. In a strict interpretation you are correct but, based on MeshCAM history, it is acting as expected.
This strange interpretation was something I debated changing some time ago with settings to keep the tool completely in the stock. The importance went away when the new stock dialog gave users more control over stock placement. The margin behavior is an extension of the general tool containment behavior.
I did find it necessary to run the tool relatively far from the geometry so the toolpaths don’t get to broken up with lots of retracts. Early testing only require one radius of margin but there were so many retracts and little roughing pockets that it took longer than it should to machine. This may fall into the discussion we were having about other settings- maybe I shouldn’t be as strict about what values are allowed but give warnings that you could get in trouble if you go too far outside the recommended values.
-Robert
OK, so I did misinterpret the number. I was mislead in part because MC won’t let me input a number that is more than the tool radius (an absolute minimum for sure!) but less than the tool diameter. I can appreciate the tightrope you must walk to accomodate both new users and picky guys like me, but my leaning would definitely be in the direction of “informed consent” when making marginal settings.
Best regards,
Randy
OK, here’s a wacky thought (and what else is new?) that I had while waking up this morning.
Your parallel-roughing process first traces an outer boundary and sometimes island boundaries within the outer boundary. It then goes back and does furrow-plowing in the region contained by the outer boundary, and skips over any islands. The furrowing move is a plunge, a lateral move and a retract.
For a flat endmill, any furrowing move with a length equal or less than the cutter diameter won’t be removing any material, since the boundary passes it’s connecting will already have cleaned out that material. For a ball endmill, any move less than about .75 cutter diameter will only be cleaning a little cusp.
Not knowing the internal logic of your roughing routine, would it be possible to set a test and just not do any moves that are less than 1.0 (flat) or 0.75 (ball) diameters?
I can’t think or sketch a situation where that would be counterproductive. But I’m an amateur, so take this for what it’s worth…
Best regards,
Randy
I think that is a good suggestion. The only problem is that there would need to be logic that detects when it would be counterproductive to remove one little run because it would create a retract that would take more time. This type of feature is deceptively difficult because it usually generates a lot of feedback about what “optimal toolpath” means to different users with everything from a Sherline to a Haas.
The other think I’ve toyed with is removing the boundary tracing from the roughing to save time. I think the next roughing version will look into this further.
OK, Robert. If it was just plunging once and saw-toothing along the narrow part I wouldn’t even have brought this up. But in watching my mill, all the little runs that are between closely-spaced boundaries (where the boundaries are close to orthogonal to the runs) each have a plunge and retract. It’s all the plunging and retracting that take the time.
I’ll be sad for the boundary tracing to go. It’s my favorite part watching the roughing!
But, in the case of narrow areas to rough, the boundary tracing pretty much is all the roughing that is required. What if, after you traced the boundaries, you offset them “inwards” (into the interior) of the area by a cutter radius and used the new boundaries for the rastering? (I realize there would potentially be a lot of overlapping boundaries to clean up, which I don’t know if your routine is already prepared to handle.)
Best regards,
Randy
OK, strike that last thought (except for the short single run part…) I typically use 50% stepover while roughing, but other people will use more or less. That will vastly change the effectiveness of reducing small moves. I really don’t envy your job in writing MC!
Best regards,
Randy
No, destrike the previous thought. The initial boundary traces will always do a full cutter’s width of roughing, no matter what the stepover. So would an initial parallel pass at a given level. The boundary tracing will be the most efficient in clearing narrow areas at the new level. Now I’m going to find someone’s grandmother to teach sucking eggs to. ;p
Best regards,
Randy
Robert, there is a small UI inconsistency in the Support Dimensions dialog. It does remember the last settings used, but if I enter a new height and/or width by hitting the enter key to establish them, the dialog resets the vertical position to top of geometry and enters that number in the Other box (although not selected).
If I enter the height and/or width by hitting the tab key to establish them, MC keeps the existing Vertical Position settings. Would it be possible to keep that behavior when using the enter key when entering the height and width settings?
Due to having only a top view when generating supports, I need to exit the dialog, rotate the view around to see where the supports ended up, and many times go back and erase the supports, tweak the vertical position and re-generate them.
What would be REALLY nice for folks like me who make weirdly-shaped stuff, would be a split-screen display, with a side view showing the plane of the potential supports when I enter the vertical position. That would reduce the iterations needed to generate useful supports…
Thanks,
Randy
I second that last statement, I have to spend alot of time getting the supports just right. Having two views would really help.
Thanks
Jay
My thoughts on roughing boundary tracing…
I really like it for the first pass. A quick check that my stock is the right size and the vice might live another day. (It could run at a reduced feed rate) After that I walk away and don’t care, roughing efficiency is not a great concern for me, 90% of my run time is finishing and I’ve learned not to worry about even that.
Jeff
I think I may make the boundary tracing optional since a check box won’t take up much room in the UI.
For the supports, here’s an idea: MeshCAM would add a transparent ghost plane at the Z level of the supports. You will be able to rotate the geometry and a support will be added wherever you click on the plane. Not sure what technical hurdles will pop up with this approach but it might be a good compromise.
-Robert
Robert, both ideas sound good. I don’t know how many times that I’ve accidentally erased a just-placed support by forgotting and trying to right-mouse drag to zoom out and then spin the model around to see if the support ended in the right spot…
Best regards,
Randy
One more- V3 will have an additional support mode where you can click on the start and end point of the support to place it manually with any orientation you want.
-Robert
Robert, that sounds good.
For me the important thing is minimizing the margin around the geometry when doing double-sided machining. Even acrylic in thick pieces gets pretty expensive, much less aluminum. The ideal (again, in my opinion) is supports that are not much longer than a cutter diameter. This helps both in rawstock optimization, and in the stiffness of the supports themselves. I’d much appreciate anything you can do to accomodate that concept, in whatever development direction you take.
Best regards,
Randy
OK- you win. The release after next will make the diameter+10% a recommendation rather than a requirement.
-Robert
Robert,
Thank you, sir. I’m fully prepared to accept the consequences of my actions. “Informed consent.”
But I don’t need to “win” if you think it will be detrimental to your user base in general. I’m happy/eager to put my ideas out as food for thought (my wife says I should not be so brutally forthright in voicing my opinions
) but that is all they are–one guy’s opinions.
That said, I very much appreciate your accomodation of even single users. You must have a bunch of guys routing big signs out of MDF and urethane foam that don’t care a whit for an extra inch or two of rawstock.
Best regards,
Randy