Comments for MeshCAM Development http://www.grzsoftware.com/news Mon, 01 Dec 2008 20:19:42 +0000 http://wordpress.org/?v=2.6.3 Comment on ZMap Elimination by Randy http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7662 Randy Wed, 26 Nov 2008 19:47:48 +0000 http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7662 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 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

]]> Comment on ZMap Elimination by Randy http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7661 Randy Wed, 26 Nov 2008 19:07:56 +0000 http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7661 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 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

]]> Comment on ZMap Elimination by Randy http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7660 Randy Wed, 26 Nov 2008 17:56:28 +0000 http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7660 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, 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

]]> Comment on ZMap Elimination by Robert http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7659 Robert Wed, 26 Nov 2008 17:06:27 +0000 http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7659 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. 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.

]]> Comment on ZMap Elimination by Randy http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7658 Randy Wed, 26 Nov 2008 17:01:52 +0000 http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7658 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 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

]]> Comment on ZMap Elimination by Randy http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7657 Randy Wed, 26 Nov 2008 04:07:37 +0000 http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7657 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, 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

]]> Comment on ZMap Elimination by Robert http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7656 Robert Wed, 26 Nov 2008 03:24:54 +0000 http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7656 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 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

]]> Comment on ZMap Elimination by Randy http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7655 Randy Tue, 25 Nov 2008 23:42:16 +0000 http://www.grzsoftware.com/news/2008/11/24/zmap-elimination/#comment-7655 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 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

]]> Comment on MeshCAM 7151 by Randy http://www.grzsoftware.com/news/2008/11/13/meshcam-7151/#comment-7654 Randy Tue, 25 Nov 2008 06:30:28 +0000 http://www.grzsoftware.com/news/2008/11/13/meshcam-7151/#comment-7654 Robert, thank you. I very much appreciate the time and effort you have spent to bring MeshCAM to the point it is, and it is only getting better at each release. Looking forward to V3! :-) Randy Robert, thank you. I very much appreciate the time and effort you have spent to bring MeshCAM to the point it is, and it is only getting better at each release. Looking forward to V3! :-)

Randy

]]> Comment on MeshCAM 7151 by Robert http://www.grzsoftware.com/news/2008/11/13/meshcam-7151/#comment-7653 Robert Tue, 25 Nov 2008 04:09:47 +0000 http://www.grzsoftware.com/news/2008/11/13/meshcam-7151/#comment-7653 Randy- It's currently 1e-8 from the top of stock. I just changed it to 1e-6 and made it so you can change the value from Lua. If 1e-6 doesn't work for you in the next release then let me know and I'll give you the Lua command to change it. -Robert Randy-

It’s currently 1e-8 from the top of stock. I just changed it to 1e-6 and made it so you can change the value from Lua. If 1e-6 doesn’t work for you in the next release then let me know and I’ll give you the Lua command to change it.

-Robert

]]>