Ramping is almost certainly only required in support of slewing, even the tracking of an LEO object is only around 120 arc src. per second, about eight times sidereal rates and well within stepper start-stop rates. In an open loop system, the role of slewing is to move from one point to another in the shortest time without missing or gaining a step. The problem, of course, is that when stepping above the start-stop rate, sudden large changes in the step rate will result in missed or gained steps. The solution then is to make a series of smaller changes so as to arrive at the desired step rate over time rather than all at once. The optimal being a small change each step so as to advance, or retard, the coil current in relation to the actual rotation and to maintain a smooth rate of change.

For a first stab at this problem let's assume we start tracking in the desired slew direction, then we set every step pulse time to 0.99 times the last step, we keep this up until we reach the mid-point of the slew, then we set every step pulse time to 1.01 times the last step and continue until we reach the slew target. Any solution this nice and clean and simple has to have a catch, right? Of course it does, two of them in fact, and one's a show stopper. The fatal problem here is the simple fact that our steppers will only run so fast, and even at a 1% ramp rate we'll be over the stepper's step limit in almost no time. As a result this scheme will only work for very short (a fraction of a dregree, at most) slews.

So, now, the 'other' scheme. We start out tracking in the desired slew direction, and ramping our steps at 0.99 times the prior step, just like before, but now we compare our step time to a 'max step rate' register after each step, when our new step rate exceeds the 'max step rate' we a) stop ramping up, and b) starting counting up steps. When we reach the mid point of the slew, we start counting down on the same register untill we reach zero (this is the 'flat top' of our slew rate profile). Now we we set every step pulse time to 1.01 times the last step untill we reach the slew target. My first thought upon reaching this point was that all this was taking up a rather large pile of gates in order to get the job done. This was quickly followed by the realization that it will not handle short slews when the slew rate fails to reach 'max step rate' by mid-slew. But, just a little more logic to cover the case of reaching mid-slew while not exceeding the 'max step rate' takes care of that, so I decided to code up a simple simulation in order to 'play' with ramp rates, etc. This is when I ran into the other problem, one of those "Oh yea, of course" things that I never seem to think of prior to stumbling over them.