Question: I've done a fair bit of reading on stepper motors and acceleration.
I had to wade through a lot of different strategies with a lot of calculations, including one which called for several candles, and "A maiden of virtue pure" Which while interesting, seemed impractical (Not enough space on the Arduino)
Basically they all boil down to this:
"Accelerate using some type of ramp, run at speed, then decelerate to stop"

All good. Accelerating will get the load moving, and smooth deceleration will get the load to stop at the (hopefully) correct position.

My issue is this. All of the reading I've done so far seem to have the assumption that the distance to travel will be enough to accommodate all three phases of travel. ie Accel, Coast at speed , Decel.
I've not found much discussion on how to handle very short distance situations.

For example, moving only two steps will not, can not possibly have enough distance to go through all three phases. step - step - done.
While that particular example seems to be simple enough to solve, what are the best ways of determining if deceleration is required, and if so, when?

At what point do I determine that some sort of deceleration profile will be needed to get the stepper to stop at the required position without overshooting.

---

So after a whole bunch more looking, and reading and getting confused I decided on the simplest solution.

I stayed with a trapezoidal/triangle profile.
Essentially I determined the distance a constant acceleration ramp would use to get to speed. If the acceleration distance was greater than half of the total distance to travel, I accelerate for only half the total travel distance and not worry about getting to max speed. Because I decided to use a symmetrical approach, the decel part took care of itself.

The equations I utilised are essentially the ones posted by Chuck, although the addition of different acceleration and deceleration rates he uses gives me food for thought.

Many, many thanks to all who contributed.

Answer: 
Well, for short runs, it should be obvious that you can skip the coast phase.

As for the others, it's pretty simple. Maintain constant acceleration until you are halfway to the target, then decelerate until you reach the target.

However, there's a catch (there always is, isn't there?). If you have misjudged the distance to the target, and it is closer than you think, then accelerating to your (erroneous) half-way point will mean that you will not be able to stop when you reach the real target point.
I gave you links of simple traj. planner from linuxnc.org. It has to be noted that is not in use since it has been superseeded by new and better (more complex) one.

[wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple\_Tp\_Notes](http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_Tp_Notes)

[Source code](https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/simple_tp.c)

So, how it works:

At the beginning you set **pos\_cmd** = **curr\_pos** (actual position), the planner does nothing. Then you set a new **pos\_cmd** (setpoint position) and **vel\_req** (setpoint velocity) with constraints: **max\_acc** , **max\_vel**.

The algorithm computes for each step (recursion) the distance to stop regarding the actual velocity, actual position, max\_acc. 

If the position to stop is equal or bigger than actual distance to stop, then it begins to coast.

Else if the current velocity is smaller than vel\_req it ramps up with max\_acc ramp.

Else if the current velocity is equal or grater than vel\_req, then it moves with constant velocity.

It has to be said that this is pure open loop control, no feedback. The planner generates trapezoidal profile and outputs setpoints for position and velocity and the drive has to follow it. As said it may not stop at exact position, see notes.

P.S: IMO the article you have proposed is more specific fo use for stepper motors, in fact it calculates pulses. The linuxcnc is more generalized approach, but you can have a wider look for your problem. There is no flaw using a planner either for small or large movements, all calculations are limited by phyisical constraints that are input as parameters.