Hi Gene, I don't fully understand your question, but I have reason to think that my fixes will improve position tracking accuracy and consistency, and may help in the scenario you describe.
In case you're not familiar with motion's internals, here's what happens at the start of a position sync move (rigid tap, G33 threading) 1. Wait at the start of the thread for an index pulse (i.e. motion progress is 0). 2. At index, spindle position (in revs) is now 0 3. Start "sync accel", i.e. accelerate at maximum rate to match speed with spindle 4. Once the axis feed and spindle speeds match, we declare that point to be "synced". Save the current spindle position and motion progress internally. 5. Now, we track / correct position error relative to this sync point. Without the "sync accel" phase, the initial position error would be very large, which could lead to overshoots and a long settling time. There were a few subtle issues with the implementation that may reduce threading accuracy: The biggest issue I see is estimation of velocity for low PPR encoders. Currently, motion estimates velocity with a simple backward difference. This leads to a very jittery velocity estimate. For example, at 120RPM with a 100PPR encoder, we'll see once pulse every 5 servo interrupts (@ 1kHz). Our naive velocity will swing between 0 and 600 RPM. This is a problem for a few reasons: - sync accel is over when axis velocity >= spindle speed * uu/rev. In the above example, sync accel will never last more than 2 timesteps, leaving a large initial position error. - Spindle speed jitter appears in axis motions as acceleration spikes (see issue 164 <https://github.com/LinuxCNC/linuxcnc/issues/164>) - There will be a steady-state error, because the velocity "peaks" are rarer than the troughs, and the correction is rate-limited by the maximum axis acceleration. The simple fix here is just to provide a better spindle speed measurement. Most encoder counters can do this already, so we get the benefit for free. On Sun, Dec 11, 2016 at 12:18 PM Gene Heskett <ghesk...@shentel.net> wrote: On Sunday 11 December 2016 09:17:32 Robert Ellenberg wrote: > Ahh, that would have been smart to include before: > > - sim_spindle_encoder's position signal is now quantized based on > encoder resolution. > - Use motion.spindle-speed-in as the velocity reference for spindle > position tracking (falls back to old velocity calculation if this > pin is unconnected) > - Tweak position error correction math to reduce acceleration > jitter - Add a HAL pin, motion.spindle-tracking-gain (range 0.0 to > 1.0) to control how aggressive position tracking is. 1.0 is stock > behavior, 0.0 is no position tracking. > - Fix "sync_accel" phase of position tracking for low-count > encoders. - Experimental fix for issue 167 Was this caused by an attempt to get z in position closer or effectively on the index by the time it has arrived at the workpiece, thereby reducing that thread wrecking spindle speed vs phase of the thread change that occurs when the operator sees that everything clears and cranks up the rpms to cut a cleaner thread? I had noted a rather large, wrecked the thread, change in the cutting tip position vs thread clear back in 2.5 IIRC while using g76. The cause was explained as being the time to accell to a locked phase, which caused the thread to move to the right. By over accelerating Z, if it had the headroom to do so, such that the actual spindle to Z stayed effectively at the index pulse seemed like a good idea. If it doesn't have the headroom to catch up by the time it arrives at the work, there will be bad threads cut at the entry. That of course can only be derived if the g33 knows how much room it has to get that done. I wrote some .hal code that if I put a halmeter on its output, that tells me the number of encoder edges between motions reversal to effect the backout move for telling me how long in encoder counts between motions issuance of the spindle reverse, and the first encoder pulse received in reverse direction. That was to aid me in preventing broken taps because it had hit the bottom on the drilled hole. A calculator can quickly convert that into distance traveled, overshoot if you will. With the needed accell limits to keep from breaking flimsy drive parts on TLM, it quickly became obvious that the practical limits for threading rpms was well below 300 rpm, and more practically around 200. At 600, cutting air, the overshoot was around 9 turns of the chuck, at 300, around 2.5, and at 200, about 1 full turn. Somewhat interesting was that it did the reverse in high gear faster, in low gear the higher MV2 energy in the massive flywheel/pulley/cooling fan of the motor actually slowed the decel to stop rate. > <https://github.com/LinuxCNC/linuxcnc/issues/167> by popping an > error message to the user and reducing spindle speed (if possible) - > Fix for issue 68 <https://github.com/LinuxCNC/linuxcnc/issues/68> by > disabling blending at start of G33 (to be consistent w/ 2.6.x) > > Backend changes: > > - Group some spindle status variables into struct: > - Motion spindle command outputs are in a struct called > "spindle_cmd" in emcStatus > - motion spindle inputs are now in a struct called "spindle_fb" > - Math tweaks to rigid tapping / position tracking to prevent > discontinuities due to sign changes. > > -Rob > > On Sun, Dec 11, 2016 at 8:20 AM andy pugh <bodge...@gmail.com> wrote: > > On 11 December 2016 at 06:30, Robert Ellenberg <rwe...@gmail.com> wrote: > > For anyone interested in testing, my latest branch based on Peter's > > suggestion, and a bunch of other spindle tracking fixes is here: > > Can you explain what is changed and improved? 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> ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
