-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exceeding final position when acceleration change in ramp #35
Comments
@tobo-123 as far as I can remember this is not a known behavior. Can you also quantify the overshoot? How many steps and at what speed values are you overshooting? I honestly never testet the behaviour if you change the acceleration/deceleration values when you are already in an acceleration/deceleration window. |
Hey, here is a sketch of the program. PotiSpeed and PotiAcc are integer values in the range of 1-100. The overshoot is pretty heavy, seems to depend on the amount of acceleration/deceleration reduction and is sometimes more >300 steps. My setup crashes in the limit switch so its hard to measure the steps. This loop runs in an own task:
|
I have been thinking a bit about the problem. Could it be that the following is happening? If the deceleration is changed in the ramp, the further deceleration takes place on a flatter curve, the original target x is overrun until the speed is 0 at position x', then there is a return movement to the original position. I may not be able to see this return movement because I am already in the limit switch. Is that possible? |
Do you experience the overshooting problem only when you change from a higher deceleration to a lower deceleration value or also the other way round? And just to be sure: if you do NOT change the deceleration value after deceleration has started, you are not experience overshooting, is that correct? |
I did some additional testing today: The overshooting only occurs when lowering deceleration in the ramp. The final position seems to be reached exactly when I increase deceleration in the ramp.
Yes, when I don’t change acceleration/deceleration values everything is fine and the positions are reached exactly. I did another test and changed my program a bit:
Now I only go to position 2000 which gives me more length on my axis to see whats happening without reaching the limit switch. I saw the behavior I tried to sketch in my little drawing: When lowering deceleration in the ramp, I overshoot the position, the motor decelerates slower, stops, starts to move in the opposite direction and finally stops at the planned position. |
Basic move like stepper_1.setStepsPerMillimeter(400); Also overshoots for me In my setup I have stepper_1.connectToPins(STEP_1, DIR_1); // Defaults stepper_2.setSpeedInStepsPerSecond(SPEED_IN_STEPS_PER_SECOND); stepper_1.startAsService(0); Values are const int SPEED_IN_STEPS_PER_SECOND = 25600; I suspect its something I am doing wrong, because Example7_DualAxis works for me. But i want to use blocking move instead of setTargetPosition [edit] Works correctly, instead of stepper_1.moveRelativeInMillimeters(32); (using the while to block) |
@petervanderwalt sorry, I am not sure what you want to achieve and works or doesn't. You speak about blocking moves (I assume you mean the blocking functions in the library) but you are starting the library as a service (which is non blocking). |
Hi pkerspe, any news on my issue? I guess it's not necessarily a bug of the library, but a behavior to be aware of. I think it would be good to point out this behavior in the documentation. It would be great to have a function that checks whether the target can be reached safely with a new decelleration value and returns this as true/false. Then the user could prohibit writing new decelleration values. Would that be feasible? |
Sorry for the delay. Currently on sick leave and was to busy with other tasks the last weeks. I guess it should be easy to provide a function that returns if a ramp is active, will check this week! |
Can you try using getCurrentVelocityInStepsPerSecond() and comparing to your set max speed? That way at least you should see if you are in a ramp |
Thanks for your quick reply. Comparing current velocity with set speed is a good idea, I'll try that. But I don't think it completely solves the problem. As far as I understand DeterminePeriodOfNextStep(), a reduction of deceleration shortly before the calculated start of the ramp should also lead to overshooting. Therefore, a function that performs a calculation would be best. |
Here my idea of a new version of the setDecelerationInStepsPerSecondPerSecondNew:
It only "accepts" new values if the newly calculated ramp is not longer than the current distance to target. What do you think, can this work? |
Hi, What I am seeing is that if that the target decc is diferent than de acceleration, then is giving the target complete when it lacks some pulses to finish. PROGRAM sample to go 20 rev to one direction and 20 revolutions to the other direction See the osciloscope signal: The system is still sending Pulses when is sending the stepper to the other direction. Really thank's, Carles |
Hello,
First of all, thank you for the great work, working with the library is a lot of fun, also because of the good documentation.
However, I am experiencing the following problem: I use the library to move a closed-loop servomotor back and forth between two fixed positions. I read in values for the speed and acceleration via two potentiometers, which I enter accordingly via setSpeedInStepsPerSecond and setAccelerationInStepsPerSecondPerSecond and setDecelerationInStepsPerSecondPerSecond. I use the startAsService - mode.
If I now lower the acceleration/deceleration value during the deceleration ramp before reaching the end point, the motor moves past the end point.
Is the error with me or is this a known behavior?
Best regards
tobo
The text was updated successfully, but these errors were encountered: