On Friday 11 April 2014 12:37:38 Jon Elson did opine: > On 04/11/2014 12:41 AM, Gene Heskett wrote: > > The main reason I was concentrating on the limits, using > > the same code, was that I had written a peck cycle wrapped > > around a G33.1, which advanced half a turn per run in. I > > had moved the code back away from the workpiece, basically > > cutting air, and had noted that on some occasions, the > > spindle became unlocked from Z with Z stopping while the > > spindle ran on for 3 or 4 turns, > > > > And I haven't checked (I have to think about this stuff & > > then go back & check) as to whether the soft limits move > > with the touchoff or not. > > The soft limits are in machine coordinates. They > should be established when you home the machine, > and should not be altered by touchoff, G92 or anthing > else that affects WORK offsets only. > > Now, unless somebody worked on it with this in mind, I > could easily see how you could have a threading cycle that > would exceed a machine limit (I guess that would be +Z) > that might not be detected by the trajectory planner. > The T.P. can't know how long the spindle will coast when > powered off, so it could end up coasting backwards beyond > the machine limit, if the start of the thread was just barely > below the +Z limit. > > Jon
In actual practice, at least here Jon, hitting the +Z limit is astronomically unlikely, assume +Z is to the right when viewing the lathe from the normal, spindle on the left, perspective. But my homing procedure, sets Z0.0 at the face of the chuck +.005". So while a tap is never homed against, its still possible for the forward, into the hole stroke of a g33.1, to exceed that MIN_LIMIT if the work is chucked too deeply. IMO to prevent work or tool damage, the reverse should be issued at the limit point, and coupling should be maintained during the turnaround until the tool is backed out at lest to the start point, then do the e- stop. That is not how it works today because the backout continues until the spindle has stopped, at which point Z runs very rapidly left to the synch point. Or is that an artifact of my wrapper? The code in rigid- tap.ngc: ( This is a routine to successively deepen a tapped hole in something in the chuck ) ( We have the G38.1 canned cycle, which does one pass only but seems to track well ) ( So here, we do repeat loops of the G33.1 by advancing the z value by some fraction ) ( of a turn until the desired depth has been achieved, or we've broken the tap ) ( first, establish the starting point ) ( first set spindle slow ) ( the G33.1 code needs help. Its the only spindle synchronized move that tracks ) ( the axis after issuing the reversal command, BUT it spends so much time in the ) ( overshoot past the stop points region that the whole thing wastes a lot of time, ) ( perhaps 75% of the time if the spindle braking is slow or non-existent ) ( Top that with the fact that it may be tapping a blind hole, and the tap may, ) ( in the overshoot, hit the bottom of the hole and break it. This is not ) ( excusable behavior. ) ( In the meantime, a SWAG as to the overshoot needs to be made, and the ) ( end points are then adjusted so as to "pre-issue" the reversal commands ) ( so that the actual end points achieved are much closer to the targeted values ) ( set in #<_hole_start> and #<_tapped_depth> variables. ) s250 m3 g4p1 (give it time to speed) #<_hole_start> = 0.3000 ( just out of the hole ) ( Next, set the stop point, but be sure the hole is actually drilled that deep! ) #<_tapped_depth> = -0.3000 g0z#<_hole_start> ( Next, set tpi, calculate eventually ) #<_thread_tpi> = 32 #<_per_rev> = [1 / #<_thread_tpi>] (debug,per_rev=#<_per_rev>) ( Next, set increment, try at 1/2 turn ) #<_per_pass> = [#<_per_rev> /2.000] (debug, per_pass=#<_per_pass>) ( Now, plug in our SWAG of the overshoot, 2.5 turns at 300 rpm as a guess ) #<_this_depth> = [#<_hole_start> - [3.00 * #<_per_pass>]] (debug,this_depth=#<_this_depth>) G0 z#<_hole_start> ( Now we have enough info to set up a loop to peck tap a hole ) o100 while [ #<_this_depth> gt #<_tapped_depth>] g33.1 Z#<_this_depth> k#<_per_rev> #<_this_depth> = [ #<_this_depth> - #<_per_rev> ] ( do this pass ) (debug, target depth=#<_tapped_depth>) (debug, g33.1 z#<_this_depth> k#<_per_rev>) (g4p1) o100 endwhile (debug, done) m5 m2 So it doesn't seem to be in my code. FWIW, this code will not run past the first stroke in the present 2.6.0-pre sim lathe, limits out & e-stops at about -.001 Z. But its the code I used to tap a hole for 8/32 accessories in the end of a brass ramrod for a 50 cal BP rifle last spring. 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 ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
