#24 Backlash compensation errors

(not used) (12)

While using backlash compensation, the
machine appears to be losing steps very badly.
I have spoken with John Kasunich about this in some
detail, in IRC.

What appears to be happening, is that during programs
that use a large number of directional changes, the
compensation movement ramping is happening faster than
the stepper motors can react, causing lost steps to
This happens no matter how fast or slow the machine is
acutally moving.

Removing backlash compensation (setting it to zero)
removes the error.

Examples can be seen here -



This is the "dome" program that comes on the programs

This error is also very evident during text engraving
programs, due to the same types of high numbers of axis


  • John Kasunich

    John Kasunich - 2005-05-17
    • priority: 5 --> 6
    • assigned_to: nobody --> jmkasunich
  • John Kasunich

    John Kasunich - 2005-05-17

    Logged In: YES

    This is _probably_ a result of the "fix" that Fred and I added
    at EMCFest 2004. The old backlash code attempted to use
    accel and decel ramps when applying the backlash compensation.
    It works, _unless_ another direction reversal takes place while
    the compensation move is in progress. In that case, the portion
    of the move that was not yet completed becomes a position error
    that does _not_ go away on subsequent direction reversals, in
    fact it can accumulate.

    The "fix" was to put in a simpler version of the backlash move that
    correctly deals with reverals at any time. However, the new code
    does not to accel/decel on the backlash comp move, it simply
    makes the move at a constant speed. For servo machines this is
    acceptable - the PID loop ensures that the motors track the desired
    path and recover even if there is a momentary error due to the fast
    accel of the backlash move. (If backlash is large this may result in
    a following error however.) On stepper systems where the step
    generator itself applies accel limts, it is also no problem, the motor
    runs within its limits and the PID closes the loop. However if the
    step generator doesn't apply accel limits, the sudden accel and
    decel of a backlash move can cause lost steps.

    For a short term fix I will probably replace the original code, with
    an ifdef to select between the new and old code.... pick your bug
    based on which one will hurt you.

    The proper fix is a better algorithm for applying the backlash
    compensation that ensures the commanded path never exceeds
    the motor's accel limit. (Or a downstream step generator that
    never generates steps that the motor can't follow, and let the
    PID handle the lag that will happen on a fast accel.)

  • John Kasunich

    John Kasunich - 2005-05-25
    • priority: 6 --> 3
    • status: open --> open-later
  • John Kasunich

    John Kasunich - 2005-05-25

    Logged In: YES

    At least some of the problems on Weylands machine may
    have been due to PID tuning which made it more vulnerable
    to lost steps. Weyland's problems were solved by moving
    him over to EMC2. The EMC2 step generator doesn't need
    PID tuning and automatically limits accel and decel rates.

    Since EMC1 is now deprecated, further work on this issue
    will be deferred indefinitely.

  • John Kasunich

    John Kasunich - 2005-06-09
    • status: open-later --> closed-later

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks