On Monday 29 September 2014 18:57:25 David Nicholls did opine And Gene did reply: > Hello, > > I need some advices regarding spindle synchronized motion on LinuxCNC > 2.6.3. I rebuilt the machine that drives my CNC knee mill a few days > ago and I can't get the tapping sequence to work correctly. The Z axis > motion waits above the hole while the spindle accelerates to speed > (which I believe is quite correct), it then moves the Z axis to tap the > hole. When it gets to the bottom of the hole, however, it seems to > hold the Z axis still while the spindle decelerates. It also holds > the Z axis still while the spindle accelerates back up to speed (in > the reverse direction) before moving the Z axis back up to the top of > the hole. I've recorded it on video to demonstrate what I'm trying to > say. The video can be seen at > http://www.youtube.com/watch?v=8KEfMRF1yx4 > > I had this working correctly on LinuxCNC 2.5 and I haven't made any > changes to the electronics since then. I chose to do a full machine > rebuild using the Debian Wheezy ISO image from www.LinuxCNC.org. I > used the PNCConf wizard to generate my configuration files and, as far > as I can see, they don't look drastically different to those that used > to work. > > The GCode I'm running is "G33.1 K0.7 Z-18". > > Can anyone suggest somewhere for me to look? I expect there are lots > of people doing rigid tapping and so I can only imagine that I've > configured something poorly. Rather than publishing my whole > configuration, I was hoping that someone might suggest an avenue of > investigation. > > Thanks > David Nicholls
I am doing it on a lathe, and I have seen that occur. From what I can deduce, its running into the - limit on z, stopping the carriage, but keeping track of where its stopped and picks Z back up in the back out move as its internal z position matches where it stopped. I have mentioned it on this list as I would consider that a bug since it broke a couple taps for me. But now I've moved the software -z limit, which I originally set so as to not crash the carriage into the bottom of the potentially spinning chuck, which is also not exactly a Good Thing. How this would react when hitting a real limit switch as opposed to the software setting I haven't a clue since I don't have any "real" limits switches, just homes. So I would consider moving the SW -limit below where it now is, by a good 2", and with a tap lightly held, or with no tap mounted, see if it repeats. No use breaking a tap to test, its obvious when it happens. A software limit is not movable with a touch off, its in the original machine co-ordinates. But you can move the motion with touch off to test the theory. This is a bug IMO, and should be checked and reported at gcode load time. But, in mailing it down to confirm, I would move it down with the touch off as it should be possible to demo this by hitting the -limit while inside the reversal motions, IOW after the spindle has actually started to slow. In that case, there is likely no way LinuxCNC can test and warn because it has no knowledge of the expected over travel, which on my lathe, is about 2.75 turns starting at 300 rpm. A hair over a turn at 200 rpms, and about 5/8's turn at 100 rpms. If interested, I have some hal boilerplate that will show the overtravel, which in my simple code, is displayed in encoder counts, that will measure and report the over travel while its reversing. Display it with a hal meter. Use the result in the target depth to tap by subtracting 75-80% of it. # Now, lets see if we can track the G33.1 turnaround over travel # first, make a sum2 into a sub2 setp sum2.ovrtrvl.gain0 -1.0000 # then net the sample-holds but sample needs s32, not float so use encoder count net ovrtrvl1 hm2_5i25.0.encoder.00.count sample.dirchg.in sample.spndlchg.in net spindle-ccwcmd motion.spindle-reverse sample.dirchg.hold net spindle-reverse abs.encdir.is-negative sample.spndlchg.hold # and measure the over travel in encoder slots that went by from the s32's 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 should be shown with a hal_meter. I am hoping that a better way to handle this can be developed if a discussion can be started. If indeed you're hitting the same thing I seem to have hit 5 or 6 times. Startling when it happens, doubly so when you also hear the click of a shattered tap. 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 ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
