Thanks Rob, Comments below. > -----Original Message----- > From: Robert Ellenberg [mailto:rwe...@gmail.com] > Sent: January-20-21 10:12 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] Spindle speed changes with threading. > > Hi All, > > As others have said, during position-synched moves, the axes follow the > spindle position, so you don't need fine control of spindle speed. However, > you should have both a stable spindle RPM and a high-ish resolution encoder > to get the best results. John, for your example, as each encoder pulse > arrives, the TP will be constantly accelerating / decelerating to try to > track that position signal. Luckily, it can't get too far off because of > the axis acceleration limits, but the amplitude of the jitter will > definitely be higher with a low resolution encoder. > > Here's how spindle synchronization broadly works from within the TP (i.e. > what occurs in motion after START_FEED_SPEED_SYNCH) > > 1. The TP waits (with axes stopped) for a spindle index mark. > 2. Once the spindle has just passed the mark, the machine axes > accelerate until they reach (spindle speed * requested units/rev). > 3. Once the axes reach the expected velocity, then synchronization is > declared, and the TP maintains position synchronization from that point > onwards. At higher spindle RPM, synchronization takes longer, so the > spindle rotates farther before the axes are synchronized. Multiple > threading passes at different spindle RPM will not quite follow the same > path. > 4. After synchronization, the TP computes a position error based on the > measured spindle position. The axis velocity is nominally spindle speed * > uu / rev, but that velocity is corrected up or down as needed to drive the > position error toward zero. > > Note that multi-start threading is not currently possible (because the TP > always synchs at 0 deg, i.e. at the index mark), but we could modify the TP > to start synchronization at some angle after the index mark.
I'm surprised that multi-start threads are not possible. I would think, assuming the spindle speed is _not_ allowed to be different, that changing the start_z position by say 50% of thread pitch that synchronizing on the index would then reliably create a two start thread. It's how I do it on my ELS. > > Finally, the obvious fix for the inconsistency in the acceleration phase is > to just declare synchronization at the index mark right away. With the axes > starting from rest, there would be a huge initial velocity error for the TP > to correct. It will do so eventually, but there are large position over- / > under-shoots until it stabilizes. Luckily, we know what the axis > acceleration looks like (based on axis max acceleration and nominal spindle > speed), so you can anticipate this and start the axes moving before the > spindle reaches the index mark. That way, the axes are moving at the > nominal speed just as the spindle reaches zero. This removes most of the > position error at the start, and the TP corrects for any residual error > very quickly. This is roughly the approach we used in PathPilot, and I > think LinuxCNC 2.8 or 2.9 would benefit from it as well. > > Best, > Rob I like the idea. Since the Z is stopped until synchronized and we know using standard physics where the Z will be after acceleration up to speed, that regardless of the number of index pulses the time from index to that same angular position should be relatively simple using time instead of index pulses. Much better granularity and doesn't force a specific encoder size. And the speed is calculated every N encoder pulses so even variations in one turn (when the spindle is turning slowly) will not impact entry into the existing thread path. John > > On Wed, Jan 20, 2021 at 12:47 PM John Dammeyer <jo...@autoartisans.com> > wrote: > > > > > > > > From: andy pugh [mailto:bodge...@gmail.com] > > > > > > On Wed, 20 Jan 2021 at 16:09, Kirk Wallace <kwall...@wallacecompany.com> > > wrote: > > > > > > > I left the trail here: > > > > > > > https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L4881-L5028 > > > > > > There seems to have been a lot of time spent investigating theory that > > > could have been settled in 5 minutes with an experiment. > > > > > > -- > > > atp > > > > Dropping an apple from a tree and observing that it falls and smashes on > > the ground doesn't splatter into the words that spell out laws of motion > > made up of bits of peel and apple. > > > > I'm assuming that the authors of this code were clever enough to take into > > account the motor acceleration relative to spindle speed on each pass. But > > that doesn't explain how they do that. > > > > And if there are 60 teeth on the spindle encoder with a single sensor then > > 120 edges are the most you get. That's 3 degrees per edge assuming the > > slots are symmetrical and I don't think there's a rule that they must be. > > Might be 1 and 5 degrees. So assume then an index single rising edge is > > used every 6 degrees. > > > > A half inch shaft has a circumference of 0.3925" and each 6 degree index > > is 0.00654". The implication is depending on spindle speed and motor > > acceleration you might be off by almost 0.006". That's a lot isn't it? > > > > John > > > > > > > > > > _______________________________________________ > > 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
