I ran a few quick comparisons using one of the hard coded variables in the interpreter. This variable is named TOLERANCE_CONCAVE_CORNER. It's found in emc2-head/src/emc/rs274ngc/interp_internal.hh and used in interp_internal.cc where there is a fascinating description of it's effects.
It does allow you to ram a cutter into a concave corner that is smaller than the tolerance set by that variable without regard to gouging. The variable is in radians so the default 0.05 works out to a bit less than 3 degrees. When the original interpreter was written it may have had this variable set to 0.01. During my comparisons I increased this to more than one radian and it will forgive the sin of writing a tool offset into a concave corner that is larger than 45 degrees. In case there are skeptics about I posted an image, http://imagebin.org/7372 That shows several passes around the outside of what would be a rectangle except for the dogleg on the right side. I kept increasing the angle of the dogleg by changing the value of the command that made the second half of this side. (y2 x##) The careful observer will note that the corner is always made at the end of the previous move and that as the angle becomes more concave, the tool will have gouged further into the second move at that point. I'd like to start a discussion here about possible changes to the code that generates this behavior so that the effect of a poorly written diameter offset program will produce a radius the size of the tool at that concave corner but not gouge the next move. IMO we would need to know the concave angle between the two moves and the radius of the cutter. We would need to stop the first move early, when the center of the cutter reaches a point on the line bisecting the concave corner. IMO again. This is a biggie because one of the constraints of the original interpreter specification was that it produce a set of canonical commands based upon what it knew of the current state of the machine and the single line of code that it was looking at. This constraint was a part of embedding the EMC into a system with limited abilities. Yes it looked ahead and made a stack of these commands but it was not set up to change previous commands based upon what a later one did. In the case shown in the image linked above, the interpreter would have to hold two commands and ask how the second affected the first. Thoughts. Rayh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
