On Wednesday 17 January 2018 02:42:51 Marcus Bowman wrote: > On 16 Jan 2018, at 23:16, tom-...@bgp.nu wrote: > > We are tying to cut some internal Acme threads on our lathe. We > > have an internal Acme 8-pitch single point tool. From the edge of > > the backside of tool to the tip of the cutting point is 0.490”. The > > major diameter of our hole to thread is 0.506. So, you can see > > there is very little clearance here. > > > > When we run G76 the backside of the tool slams into part when it > > retracts after the cut. We are currently cutting (breaking is a > > better word) wax until we are confident that something good will > > result. > > > > This causes our tool to crash into the part when it tried to retract > > after the cut: G0 Z0.100 > > G0 X0.248 > > G76 P0.125 Z-0.750 I0.005 J0.005 K0.0725 R2.0 Q14 L0 E0.0725 H2 > > > > In trying to measure things in the backplot window (not easy to do > > accurately) it appears like the tool is moving back nearly the full > > thread depth (0.075”). In this image the distance from where the > > tip of the tool is on the first retract line up to the first cut > > line which is the lower edge of that white band is about .075”: > > https://www.bgp.nu/~tom/pub/IMG_5289.jpg. Considering we only have > > ~0.010 this clearly wont work. > > I have no direct experience of using G76, but this problem reminded me > a little of the retraction distance settings on peck drilling canned > cycles in a milling machine, where the program response to a retract > distance in, say, the G83 command depends on whether there has been a > previous G99 (retract to the R value used in the G83) or a G98 (ignore > the R and retract to the original Z value used before the G83 was > begun. > > > It seems like the Drive Line is where the tool should come back to > > on every pass. If it did it would always have clearance (assuming > > it had clearance to get in the hole in the first place). But that > > is not what is happening. From the GCode reference of G76: > > http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g76 > > The documentation does say the tool should return to the drive line, > but I don't immediately understand the diagram, which shows a > different retract after each pass (the same your your own screen shot > shows). This is either being done as a result of a previous command > like a G99 or G98, or the G76 is not doing what it is supposed to do. > I note the connection between G76 and G33, but Gene knows more about > G33. > > > This is youtube video showing the tool hitting the back side on > > retraction, twice in fact before the wax snaps off: > > http://www.youtube.com/watch?v=yxHFyVMocpU > > <http://www.youtube.com/watch?v=yxHFyVMocpU> > > Wax is a good idea. Must get some. I sometimes use plastic, but the > wax looks even softer. > > > In typical threading the tool size, thread depth, and initial bore > > diameter, are such that this problem may not be noticeable. > > Often the case, with this kind of problem. > > > But with an Acme thread where the size of the tool and the depth of > > the thread (0.0725 in our case) leaves very little room for error. > > So is the G76 code broken or is there something fundamental we are > > misunderstanding? > > This is an important cycle, so it would be good to understand what's > happening here. > > Marcus
The more important point is to get the job done for Tom. But I also for some reason had a fixation on the boring head. Put it back in the box, its not needed. Does this enco have enough -x room to cut the thread with the tool mounted as shown in the youtube video? If so, this can be done with the g33.1 if the enco can reverse its spindle fast enough. Write a loop, executing the g33.1, but where one might adjust the z for use with a tap, use an increasing - x. Something like this, after touching off so xz=zero with z at least a turn out of the hole, and x centered in the hole. g7 g20 S100m3 g0z0 g0x0 #<_bottom_of_hole> = [-0.8750000 + enco's turnaround distance at 100 rpms] #<_tmp_x> = 0.0000000 o100 WHILE [#<_tmp_x> gt -0.075000000] g33.1 z#<_bottom_of_hole> K0.12500000 #<_tmp_x> = [#<_tmp_x> + -0.002500000] g1 f20 x#<_tmp_x> o100 ENDWHILE (now do spring passes) #<_tmp_h> = 3 o200 WHILE[#<_tmp_h> ge 0.0000000] g33.1 z#<_bottom_of_hole> K0.12500000 #<_tmp_h> = [#<_tmp_h> -1.000000000] o200 ENDWHILE m5 m2 Obviously replace #<_bottom of hole> with a legal -z value if the hole is not a thru hole. Because you do have a wee bit of clearance, you will likely have to adjust the value on the right of the gt in the first WHILE to get the correct thread depth. Cutting wax sounds like a heck of a good idea. To determine the overshoot, put this in your hal file. Obviously add the missing loadrt's and addf's to make it work. This is straight copy paste from my sheldon, which may have to reverse a 40 lb chuck! ========================= # calculate spindle reversal overshoot distances. setp sum2.ovrtrvl.gain0 -1.000000 # make sub2 out of sum2 # feed accumulated counts to both sample-holds net ovrtrvl1 <= hm2_[HOSTMOT2](BOARD).0.encoder.00.count # Feed both sample-holds net ovrtrvl1 => sample-dirchg.in sample-spndlchg.in net spindle-is-reversed <= abs_encdir.is-negative => sample-spndlchg.hold # that takes care of measuring reversal distance, HOWEVER, it also measures the other end # of the travel, so the halmeter jumps to a higher value at the end of the retract move as it # reverses to fwd again. SO KEEP THAT IN MIND! Read it while the retract move is running net ovrtrvl2 <= sample-dirchg.out => s32_float_cmd.in net ovrtrvl3 <= s32_float_cmd.out => sum2.ovrtrvl.in0 net ovrtrvl4 <= sample-spndlchg.out => s32_float_spndl.in net ovrtrvl5 <= s32_float_spndl.out => sum2.ovrtrvl.in1 # sample-ovrtrvl.out can be watched with a halmeter, is in encoder counts ======================== Like the shoemakers kids, someday I'll display this in the gui... Someday. :) Cheers, Gene Heskett -- "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> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
