runForward() & runBackward() behaviour

[ahmadfarisfs]

Hi gin, I'm currently testing the spi dir register, but found another things: When runForward() is executed when the stepper is still accelerating from previous runBackward() call the direction of movement did not change. Here's my snapshot of the code (sorry cannot share the full code yet):

Here's the video: https://user-images.githubusercontent.com/17040286/175760583-14805899-7ed8-47e6-aa52-beebacfa72f8.mp4

And when I change the delay to 5000 (ensure motor is in constant velocity) the direction is changing: Here's the video: https://user-images.githubusercontent.com/17040286/175760445-0d3bac50-4b1d-475e-a0b0-b633e30d0cb1.mp4

I use direct direction pin (not using spi mux'ed) on those test.

[gin66]

Thanks reporting this finding and the videos. As I am currently not at my computer, I only looked at the software. Could only spot a typo, that a comma should be a semicolon. Just this has not an impact on the functionality.

Watching the videos I have noticed, that the stepper on the first video is accelerating, decelerating, accelerating,… This means the runForward() after runBackward() has an effect. Now I am wondering: the acceleration to full speed seems to need more than 500ms. So the switch back and forth are happening before coasting is reached. Consequently, the stepper will 500ms accelerate and then 500ms decelerate, which brings it only to standstill (not reversing) and then acceleration is requested again. That’s what I read out from the first video.

To verify this: For the initial runBackward() wait only 250ms, before calling runForward(), then do the normal 500ms loop. This way the stepper should run in backwards direction for 500ms (250 ms acc, 250ms dec), standstill, run forward for 500ms (250 ms acc, 250ms dec), standstill,….

[ahmadfarisfs]

Yes, I can can confirm that the the direction do not change when motor is in ramping up, If motor already reach coasting, then if opposite run command is applied the direction will change.

[gin66]

so it works as expected.

[ahmadfarisfs]

Hi, i thought the expected behavior was even it's ramping up and opposite run command is called then the motor will go into deceleration , then accelerate in different direction.

[gin66]

it would accelerate in different direction, if opposite run command is called later. But with the timing as used, it can only come to standstill. So behavior is as expected.

[gin66]

Ok. perhaps difficult to explain in words. Let’s look at a sequence using v=1000steps/s and a=1000steps/s²:

t=0: call runForward() t=100ms: speed is 100 steps/s = 0.1s a t=200ms: speed is 200 steps/s = 0.2s a t=300ms: speed is 300 steps/s = 0.3s a t=400ms: speed is 400 steps/s = 0.4s a t=500ms: speed is 500 steps/s = 0.5s a. Now runBackward() is called t=600ms: speed is 400 steps/s = 0.5s a - 0.1s a…. decelerate from 0.5sa t=700ms: speed is 300 steps/s = 0.5s a - 0.2s a t=800ms: speed is 200 steps/s = 0.5s a - 0.3s a t=900ms: speed is 100 steps/s = 0.5s a - 0.4s a t=1000ms: speed is 0 steps/s = 0.5s a - 0.5s a

So after one cycle of 1000ms runForward/runBackward, the motor reaches standstill, if the max speed is not reached. This is independent from the chosen acceleration!

If the max speed is reduced to 300steps/s, then it looks like this: t=0: call runForward() t=100ms: speed is 100 steps/s = 0.1s a t=200ms: speed is 200 steps/s = 0.2s a t=300ms: speed is 300 steps/s = 0.3s a t=400ms: speed is 300 steps/s = 0.3s a t=500ms: speed is 300 steps/s = 0.3s a. Now runBackward() is called t=600ms: speed is 200 steps/s = 0.3s a - 0.1s a…. decelerate from 0.3sa t=700ms: speed is 100 steps/s = 0.3s a - 0.2s a t=800ms: speed is 0 steps/s = 0.3s a - 0.3s a t=900ms: speed is -100 steps/s = 0.3s a - 0.4s a t=1000ms: speed is -200 steps/s = 0.3s a - 0.5s a

This way the motor is running in reverse direction after 800ms