luni64 / TeensyStep

Fast Stepper Motor Library for Teensy boards
https://luni64.github.io/TeensyStep/
MIT License
272 stars 56 forks source link

deceleration confused #16

Closed Kahiga64 closed 6 years ago

Kahiga64 commented 6 years ago

Hello,

I noticed a strange behaviour while deceleration. It seems the speed was reduced until zero, not until pull in speed. Also there seems to be a jump from constant speed to a lower value at the beginning of deceleration. I changed the end of line 124 in StepControl.h from “… = F_BUS / (sqrt_2a sqrtf(motorList[0]->target - pos - 1) + 0 vMin / 2);” into “… = F_BUS / (sqrt_2a * sqrtf(motorList[0]->target - pos - 1) + vMin);” Was you playing around with this piece of code and did you forget to change it back to original? There is a difference in older versions of this file.

luni64 commented 6 years ago

Hi, I can have a closer look on the weekend. Would be great if you could explain what exactly you mean by:

It seems the speed was reduced until zero,

After deceleration the motor is supposed to stand still. So, the speed necessarily needs to go down to zero?

Also there seems to be a jump from constant speed to a lower value at the beginning of deceleration.

Obviously there needs to be a jump from constant to some lower speed if you want to decelerate? Do you think that the jump is too large? Can you please post the motor settings you chose so that I can try to reproduce the behavior you observed.

Kahiga64 commented 6 years ago

"It seems the speed was reduced until zero"

I expect this: . . . constant (max.) speed --> ramp down (until pull-in speed) --> jump to speed = 0 (stand still) I got that: . . . constant (max.) speed --> suddenly change to a slower speed (jump) -- > ramp down until speed = 0 (and of corse stand still) I guess the deceleration ramp starts with [max. speed - pull in speed]; it ends with zero. But it should start with max. speed and end with pull-in speed.

You removed the ofset 'vMin' (by inserting the factor 0) in line 124 in StepControl.h to calculate the decelerating. To calculate the accelerating in line 116 'vMin' takes a role.

You can reproduce this behavior by using any motor settings but slow acceleration and pull-in speed approximately 50 % of max. speed. In my project i run 2 steppers but not at the same time yet. I tried a lot of different setting. I guess you don't need my settings to reproduce the behavior. But for weekend i'll be home and i can post it.

Thanks for reply and forgive my poor English (I'm a German too) Bye, Peter

luni64 commented 6 years ago

Hi Peter, did a quick test with maxSpeed 10000, acceleration 30000 and target 20000. I recorded the generated speed profile (step frequency vs time) by making the PIT timer public (commenting out "protected" in StepControl.h)

image

I start the movement in setup() and simply print the current time and the current reload value of the intervall timer in loop().

image

I then copied the data to Excel, calculated the frequency from the reload value (f=F_BUS/reload) and generated the following graphs (they all show the same data at different "zoom levels")

image image image image

All in all I do not see any strange behavior. I can try your settings if you post them.

Here the corresponding files: files.zip

I have a look at the influence of not using v_min for the deceleration later.

Regards Lutz

Kahiga64 commented 6 years ago

Hi Lutz, thanks for showing me this way to record the speed profile. I used the same motor settings as you but i added "motor.setPullInSpeed(4000)" in void setup. Here is my record: speed profile Do you see what is wrong?

Bye, Peter

luni64 commented 6 years ago

Oh, that doesn't look nice indeed. As you already observed, the reason is the "0 x vMin" bug in stepControl.h. For small vMin's this is hardly noticeable but for your large vMin this is of course not good.

I changed the corresponding code accordingly and added a small safety check.

image

The result is probably what you want to see:

image

image

image

image

As you see in the last graph the frequency doesn't reach vMin after the deceleration phase, this is due to the fact that I calculate the new period using the current position. Would be better to start deceleration a few steps earlier to ensure that it goes down to vMin at the end. Again, for small vMin's this is no problem at all, for large vMin's this might be a problem. In case you get step losses during deceleration try to reduce vMin.

Best wishes Lutz

luni64 commented 6 years ago

Added the branch vMin_Bugfix. Would be great if you could test if the code in that branch works for you Lutz

Kahiga64 commented 6 years ago

Hello Lutz, yes it works perfect. By the way, i prefered your stepper library because it has the ability tho adjust the pull in speed. I missed that in the ordinary AccelStepper library. I need it to save time while acceleration and deceleration and to reduce vibrations and noise. Now I'm very happy and i thank you for your cooperation.

Regards Peter