Stepper motor controller

[tenaja]

I believe there is a typo in this sub...

WAddress: ' write controller address
Write 4,RData[1]
goto ReadEeprom

should read...
WAddress: ' write controller address
Write 5,RData[1] 'matches the reads...
goto ReadEeprom

[aratti]

Tenaja you are correct. Correction is necessary otherwise controller address cannot be canged. Any attempt to change the address will modify the configuration.

So please correct the write controller address code as per Tenaja suggestion.

WAddress: ' write controller address
Write 5,RData[1] 
goto ReadEeprom

Al.

[tenaja]

Al, I'd like to add one more bit of "correction" just to your description of this project. It is certainly totally usable as is, however, it is not a "true" trapezoidal accel/decel curve. To get trapezoidal curves you need fancy math that involves integrals, or some approximation of the integral that cuts it down to division.

Simply adding or subtracting a fixed time between each step does provide acceleration, but the curve comes out logarithmic. The shorter the time between steps (i.e. faster motor rpm), the faster the acceleration (steeper accel curve). This may not make a difference for many applications, but if you are trying to synchronize or optimize any motion, it is important to note.

[aratti]

however, it is not a "true" trapezoidal accel/decel curve. To get trapezoidal curves you need fancy math that involves integrals, or some approximation of the integral that cuts it down to division.

Accelleration; Velocity and travel are three quanties totaly indipendent that can be changed to suit a specific application but still totaly indipendent.

When a command travel is given, the controller start the move with accelleration as per the slope given. When full speed is reached than it will travel at full speed for a while and than it will decellerate to position. This is TRUE TRAPEZIODAL PROFILE, to understand it better, please refer to the attached picture (snap137). Surelly you have forgotten that we are using a stepper motor in a open loop and that this device is totaly time dipendent (one pulse = one step).

The quantity "ACCELERATION" is given in steps (default = 600) and this quantity will fix the slope. The algoritm will test the travel quantity you have sent (in steps) and if found greater than twice the accelleration then it will subtract twice the accelleration from the total travel to obtain the profile shown in the picture.
If the travel quantity is less than twice the accelleration then the travel profile will be "TRIANGULAR" for the simple reason that maximum speed will never be reached and decelleration will commence when accelleration is still in progress.

Simply adding or subtracting a fixed time between each step does provide acceleration, but the curve comes out logarithmic.

I don't know how much you know about log functions, but I assure you that you will never get a log function with addition or subtraction.

Al.

[aratti]

I am posting two more drawings to better illustrate the profile geometry produced by the controller.

Al.

P.S. I wish the EDIT function could be restored soon.

[tenaja]

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.

[tenaja]

By the way, to really observe the difference, set one of your motors to go to a high speed, and you can HEAR it! It starts out accelerating very slowly... then part way through, it will take off (like in the non-linear chart I attached), and IF it doesn't stall, the last bit will accelerate so fast it's difficult to discern.

BTW, I graphed acceleration in the chart above intentionally... notice how the "Time Between Steps" chart is dropping... it is approaching 0. The graphs you attached start at 0, then accelerate away from it. That's because they were generated with "Steps per Second" in mind--your motor reaches max speed when it reaches your steps/sec target.