Losing steps

[sebasu90]

test Stepper.txt

Hi, I'm using the library with a Stepper driver (only use Pulse pin and Dir pin).
I'm running an example (one revolution forward, one revolution reverse).
I notice that it's losing about 1 degree each iteration. If I let it run for a while the zero moves a lot.
I try it with different accelerations, low speeds, medium speeds.

[ryancasler]

I've noticed the same thing. Mine is much more dramatic at lower speeds though. In fact, I can actually see the motor shaft spin in the opposite direction for a brief second during the rotation. I'm using a Nema 17 stepper with a DRV8825 Stepper Driver. Using the regular stepper library i get perfect alignment back at the starting point no matter how many starts and stops I make. With this library, it never winds back up at the same place it started unless I crank the acceleration up to like 100x the Steps Per Second, which defeats the purpose of using the accel library.

[tony-maulaz]

I had the same problem, it is because during a change of direction, the signal on the DIR pin changes too quickly compared to the signal on the STEP pin. The driver does not yet take into account the change of direction and the first pulse is incorrect.
To fix the problem, you need to add a delay between the state change of the DIR pin and the pulse on the STEP pin.

[ryancasler]

But I am not making a direction change when I see the problem. Why would a problem with he direction pin cause the motor to sin in te opposite direction in the middle of a movement in one direction?
Plus, the reason that delay is not needed is because whatever stepper motor driver you are using is also going to have a delay between the time it receives the pulse and it makes the step and between when it receives the direction command and when it responds to it. As you can see from this datasheet for the TMC2209, it only takes the driver 20ns to be ready to step when a change in direction is made. It's going to take longer than that to begin stepping after the move command is made. So, I don't really think this is a timing problem.

[tony-maulaz]

Hello,
indeed with a TMC2209 there is no problem, but with other types of drivers, the time must be longer between the change on the dir pin and pulse. In this case, the library did not work.
I had to add the following patch:

void moveTo_wait(long step){
    long dist = stepper.distanceToGo();
        if(dist > 0)
            digitalWrite(pinDir, HIGH);
        else
             digitalWrite(pinDir, LOW);

      delay(10); // added delay (10 ms)
     stepper.moveTo(step);
}

Based on my measurements, the change time is about 10us, which is not suitable for the driver.

[drf5n]

I had the same problem, it is because during a change of direction, the signal on the DIR pin changes too quickly compared to the signal on the STEP pin. The driver does not yet take into account the change of direction and the first pulse is incorrect. To fix the problem, you need to add a delay between the state change of the DIR pin and the pulse on the STEP pin.

Looks like that would be here:

AccelStepper/src/AccelStepper.cpp

Line 414 in 1255ab5

setOutputPins(_direction ? 0b10 : 0b00); // Set direction first else get rogue pulses

A DRV8825 driver needs a 650ns setup time per https://www.ti.com/lit/ds/symlink/drv8825.pdf An A4988 needs 200ns per https://www.pololu.com/file/0J450/A4988.pdf

If the existing delay isn't long enough, you could add another delay after it like:

    setOutputPins(_direction ? 0b10 : 0b00); // Set direction first else get rogue pulses
    delayMicroseconds(_minPulseWidth);     // add extra dir->step delay
    setOutputPins(_direction ? 0b11 : 0b01); // step HIGH