Greetings all; Today, after fighting with it yesterday and putting in nearly 10 thou of x taper in 2.25" of Z travel before I got anywhere near a straight turn, using a dremel 1.5" diamond wheel for a cutting tool, then I wrote a similar bit of code to turn the end of the shaft down to 6.35mm, but rigged it so it was so much per inch of travel, but using a 2" cutoff wheel in the dremel, a somewhat more rigid disk than the thin steel disk, but amazingly only had to use about .0006" of taper per inch.
Since the g10L2Pn r setting only applies to G17, rotating about Z even if G18 is in effect, do we have another facility, a hal module maybe, that could be plugged in to handle what seems to be a non-trivial kinematics problem? I would like to be able to incorporate it into the system such that a certain named global variable in the header of the gcode, could set it, basically reducing it to a manageable problem instead of one that if not keeping it uppermost in your mind, can easily result in a ruined part. Or could it happen that G18 etc, or the G10L2 commands be made effect all plane assignment orientations? Either would seem to be a good fix for the problem. Ideas? Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users