gin66
Different acceleration and deceleration
Is there a possibility to have a different acceleration and deceleration in one movement. e.g. moving 100 mm with an acceleration of 3000 mm/s² and decelerate with 10000 mm/s² ?
The current ramp generator does not support this. Eventually there will be a new one, which can support this feature, but there is no plan to start on implementation in the coming weeks.
From application side, you can try this approach:
void loop() {
if (!stepper->isRunning()) {
stepper->setSpeed(500);
stepper->setAcceleration(3000);
stepper->moveTo(10000 - stepper->getCurrentPosition());
}
if ((stepper->rampState() & RAMP_STATE_MASK) == RAMP_STATE_COAST) {
stepper->setAcceleration(10000);
stepper->applySpeedAcceleration();
}
}
Hope this compiles. The stepper will run back and forth between position 0 and 10000. If in your app, the ramp does not reach the max. speed, then the proposed code will not be able to set the deceleration value.
Great library and I use it a lot, but are there any plans for the ramp generator? This is a crucial option that I'm missing. Let's say I slowly want to ramp up speed and coast for a while and then come to a relatively hard stop (high deceleration) which is a relatively normal motion profile, then this is pretty hard to realize without several tricks. A 'setdeceleration' option for a 'moveto' command would make these advanced planned motions a lot simpler. (I'm making a device where students draw a motion profile on a 2D canvas and the stepper motor executes this).
Not sure if monitoring the state for coasting is too complicated. Sure, it is more convenient to have this as an option.
A comparably straightforward implementation is to reduce the length of the deceleration ramp by a factor of 2, 4, 8, 16, or more. On AVR, division is slow, so I prefer to use only a shift operation because that calculation needs to be done on every step during acceleration.
A free choice of deceleration factor would mean recalculating the length of the deceleration ramp for every acceleration step, too.
I agree that it would be nice to have separate acceleration and deceleration profiles, but I agree with gin66 on this one, since it takes time to implement and would be mostly unnecessary given we already have a solution. I might take some time to see if I can make a fork that implements it, but that would involve figuring out how the heck this thing works and how to manipulate the internal code, so it'll take a long time if I ever do it.
