I understand your chart, but what you are missing is that the chart units are shown in Steps Per Second, not in Time Delay Between Steps. While they are related, the former is the inversion of the latter.
I've attached a quick chart I put together for you to see it. DelayTime starts out at 100mS, and then I subtract 5ms for each step until I get to a target of 5ms/step. This is linear, as you have used in your code, and yes, your "Time Delays" are linear...see the lower graph.
However, to have linear acceleration, you need to chart Steps/Sec, and make THAT linear.To demonstrate it, I also graphed "1/DelayTime". Look at how non-linear the graph is!
Think about it this way. When you go from a 100ms delay to a 95ms Delay, the "acceleration" is about 5% of the overall speed. BUT, with the last step going from 10ms to our target of 5ms per step, using your method, we are DOUBLING our speed in the last step--that is a 100% accel rate. There is nothing linear about this, in terms of acceleration.
That's why, for true linear acceleration, you have to look at the inverse of the time delay-- the steps per second. It's a long formula requiring division to approximate an integral, because if you want linear, and start out with your 5% in the beginning, then you also need to have 5% at the end... so using that rate, your final accel step would take you from 5.25ms to the target of 5ms. Come up with a quick & easy formula for THAT (to run on PBP w/o interrupts), and I'll be impressed. (I guess it could be done if you start a timer before doing the math, then adjust the time delay to compensate for the math execution time...)
That's not to say your program doesn't work--it obviously does! It's just that I had to point out that you were using your definition out of context. It makes a HUGE difference, if you are trying to syncronize multiple motors.
Bookmarks