As much as I umderstand this, could you please restate the effect/problem in ONE sentence? The picture is nice, but I still don't get something :-(
On 2/25/07, Ray Henry <[EMAIL PROTECTED]> wrote: > > 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 > ------------------------------------------------------------------------- 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
