2010/8/19 Chris Radek <ch...@timeguy.com>: > > Yes I agree the ideal solution is to know what the *desired* behavior > is and then do it - however there are two problems with that - knowing > what the desired behavior is - and then doing it. > > I don't mean to be flippant, but both are very hard. Like Stuart S > implied with his question, you don't actually program a part profile > in gcode. EMC doesn't know anything about the shape of your desired > part. It simply has a series of lines and arcs. It moves the tool > along this path, or along the right or left of it. > > If you tell it to move the tool along the right side of a certain > set of lines and arcs, but that task is impossible like in your > example, it gives an error and stops. It does not try to guess what > IS possible and maybe close enough to what you want... That way > lies madness (and ruined work). It is better to give a clear error > saying why the requested task is impossible, and then the gcode > programmer can fix the problem. >
Well, yes, fair enough! I completely understand this reasoning! EMC should not guess, what is right or wrong, but only execute the given code. Ok, but then how comes I do not receive this error, when cutting a rectangular hole in material, which is defined by 4 G01 moves (and G41 or G42 is active) - there is sharp 90 degree corner and round tool - so the corner cannot be completely reached. But somehow EMC solves the task. That is why I suspect that EMC already has some logic applied for cutting inner corners - it simply offsets the path of the tool be the amount which is equal to the half of the tool's diameter (equal to it's radius) - please correct me, if I am wrong here. And that is what should be done also in this situation - taking the example from the screenshot You provided - if the tool path was offset to the right side, the corner would be exactly where the tool is displayed. As we already agreed, that is the desired behavior. I am sorry, but I do not really understand, why it is ok for corner, where it is turn by 90 degrees, but error is produced, if the corner is sharper than 90 degrees. Are there some limitations on how the path of the tool is offset, when G41/G42 is activated? >> But I would like not to include compensation in the code so that I can >> manually tweak it, if I need it and that is why I like the G41/G42 >> commands as they do all the job. > > One thing you might consider is having the CAM compensate the path for > your nominal tool diameter but leave in the G41/G42. Then run with a > tool diameter of zero in your tool table, or if you want tweak the > path, run with a very small positive or negative tool diameter that's > the difference between your CAM's idea of the nominal tool and the > actual tool. > > This makes G41/G42 move the path only a tiny amount as if there was > a tiny tool. Offsetting a tiny amount makes it much less likely > that you will have unreachable moves. Sorry, but I do not see the difference, I still have to include the compensation in the code by CAM programm. I like the ability that I can quickly adjust the code by hand rather than doing it in CAM application or releasing clamps and repositioning the material on the table and then clamping it down again. I can still edit it manually, but having the compensation already included in the code creates more room for my mistake, so that is why I had this question. Ok, seems like I will have to live with that. Chris, did manage to check the second code sample I provided? Is EMC showing error there? Viesturs ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
