Hi Rob, Thanks for the insights. I suspected something along these lines, even if I might have other problems with noise. I can confirm, the spindle stops way too slowly and definitely more than 10 revolutions pass before stopping. Long story short, I can’t readily run the machine in back gear and the slowest I can go at 60Hz is 560 RPM without backgear. I’ll play a bit more with how quickly I can stop the spindle with a braking resistor or I’ll attempt to get the HAL file to engage the mechanical brake to help transition faster. Nonetheless, 10 revolutions seems fairly ambitious based on my best guess of how long it might take to stop the spindle even with a braking resistor. That’s about 1 second, but should be achievable. Currently the VFD is configured based on the fastest stop time for max RPM, and there doesn’t seem to be a way to decrease stop time for different inertial loads (i.e. lower gear ratios/spindle speeds). However, I understand that the braking resistor should decrease stop time by approximately an order of magnitude based on some reading I did yesterday.
Thanks! Matt > On Jul 21, 2020, at 1:00 PM, Robert Ellenberg <rwe...@gmail.com> wrote: > > Based on the videos and your descriptions of the behavior, you may be > running into a TP issue I've seen (in simulation) with very sluggish > spindles or very high spindle speeds. Here's what I think is going on: > > 1. The rigid tapping cycle allows a hard-coded 10 revolutions > <https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/tp/tc.c#L856> > of overtravel beyond the nominal bottom of the hole when reversing > direction. > 2. The spindle starts reversing direction only after the Z axis has > reached the bottom, so the spindle has to be able to stop in 10 revolutions > to stay within the budgeted overtravel. > 3. If the TP hits the end of the overtravel, it prematurely declares the > motion to be complete and stops following the spindle motion. > > Do you still see this behavior if you run the spindle slower? Your spindle > seems to take a long time to reverse, so at high speeds you may be hitting > this limit. > > Best, > Rob > <https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/tp/tc.c#L856> > > On Tue, Jul 21, 2020 at 11:18 AM Matthew Herd <herd.m...@gmail.com> wrote: > >> Ahh, so I do use limit switches and a homing routine. So it’s homing to >> the same position (plus or minus a few thousandths or so). >> >>> On Jul 21, 2020, at 11:07 AM, Jon Elson <el...@pico-systems.com> wrote: >>> >>> On 07/21/2020 04:20 AM, andy pugh wrote: >>>> On Tue, 21 Jul 2020 at 10:18, andy pugh <bodge...@gmail.com> wrote: >>>> >>>>> We are not looking for noise, we are looking for spurious encoder >> count resets. >>>> But, thinking further, even if there _is_ noise on the index line, the >>>> encoder counter should ignore it. It ignores all the _real_ indexes >>>> unless index-enable is set true in HAL. >>>> >>> Yes, the only thing I can think of is he's hitting his soft limits. Over >> time, starting and stopping LinuxCNC, >>> without homing, the machine limits will drift. If you have rational >> limits in the .ini file, you will eventually reach the end of them and have >> really strange behavior. it can be fixed by homing in a safe position, >>> but best to put in home switches and actually home the machine to a >> repeatable position every time. >>> >>> Jon >>> >>> >>> _______________________________________________ >>> Emc-users mailing list >>> Emc-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/emc-users >> >> >> >> _______________________________________________ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users >> > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
