On Wednesday 17 September 2014 10:00:04 David Armstrong did opine And Gene did reply: > Following some problems that Gene experienced with G33.1 , running the > attached program , it was found to go down to the hole bottom and then > reverse the spindle and stop waiting for whatever . > > i found adding the following courtesy of Gene , allowed the file to > continue > perhaps it may assist others or indeed lead G33.1 to be improved , as > i'm sure > most users would find this slightly perplexing to solve > I've turn off word wrapping and will reformat this for clarity. But I can't believe that it solved Davids problem either.
# added for g33.1 to work Davids comment^, below is mine Bits and pieces from my hal file. ====== # Now, lets see if we can track the G33.1 turnaround overtravel # first, make a sum2 module into a sub2 module setp sum2.ovrtrvl.gain0 -1.0000 # then net the sample holds but sample needs an s32, not a float so use # count, not position net ovrtrvl1 hm2_7i43.0.encoder.00.count sample.dirchg.in sample.spndlchg.in # freeze sample.dirchg with the ccw command from motion net spindle-ccwcmd motion.spindle-reverse sample.dirchg.hold # freeze sample.spndlchg with abs is-negative. its watching encoder.velocity net spindle-reverse abs.encdir.is-negative sample.spndlchg.hold # and calc the overtravel from s32's since sum2 needs floats 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 # the hal pin sum2.ovrtrvl.out can/should be shown with a hal__meter ====== And in my case is in encoder counts at 200/rev, so a 526 reading which is frozen in the halmeter display during the backout move, equates to 2.76 turns of over travel at 300 rpm, 5 rps, and should be subtracted from the ending depth to be tapped by the appropriate math. Hopefully we did bore the hole deep enough. My rigid-tap.ngc however, because in my case I am NOT using the tailstock feed, but have a drill chuck mounted to a threaded bar which is in turn mounted into a boring bar holder, which is mounted on a QC tool holder, So this routine assumes the user drives the cross-feed, X to center the tap in the pre-drilled hole, and therefore the routine itself has no X motion, but it triggers a bitch box from LCNC that X exceeds the travel limitations of the machine but lets you "run anyway", which it then does. Thats a PIMA, and AFAIAC, a bug and should be treated as such. I have even put in a couple of relative small X moves, putting it back where it was, but that did NOT fix the bitch box. Simply put, if there is no X(Y|Z) motion in the program, it should shut the heck up and let the operator make some money. He isn't making money when he is fishing for the mouse to click on "run anyway" for an unexpected, and false bitch box. > Dave 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> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
