PDA

View Full Version : Stepper motor controller



aratti
- 24th November 2008, 10:19
If microstepping is not an issue, then this simple project (complete with software) can be found useful.
Very compact capable of up to 2 Amps per coils respond to serial commands and can be used in a serial network.

Al.

mackrackit
- 24th November 2008, 17:56
Another one to bookmark to refer folks to.
Also...
Looks like good stuff to put on the wiki when Lester gets it running.

anonymouse
- 26th November 2008, 02:42
Very well presented, many thanks for sharing

aratti
- 29th November 2008, 11:57
The profile algorithm transforms the travel command (steps) into three vector quantities:

Vector A Acceleration from rest to fixed speed
Vector B travel at fixed speed from end of vector A to begining of vector C
Vector C Deceleration from fixed speed to rest at target point

This technique is known as "TRAPEZOIDAL PROFILE".

When the travel command is equal or less than vector A + vector B
the algorithm convert the trapezoidal profile into "TRIANGULAR PROFILE"
calculating new vectors A & B with different slopes.(1/2 total travel)

For small travel command (few steps) the algorithm was yielding very sharp slopes stalling the motor. The bug has been found and removed!

Now the motor turns smootly also with few steps travel command at high speed.

The new version software (Stepper_Driver_2) is attached, as a zipped file, to this post.

Please note that the attached schematic (very simple to build) will tremendously improve
small motors performace (max 1.2 A current)

Al.

DarthV
- 31st January 2009, 12:33
Hello to all, i´m new here and i would like to start by saying thanks to aratti for posting this nice project.
I´m thinking about use it but i wish to drive stepper motors with an model RC receiver(PWM-8 ch frame) using 2 of the 8 channels, 1 for each motor, my question is,...is it possible to add some more routines into the code in order to implement these movements and thus replace 2 of the servo motors that i have ?

thanks in advance

G.V

aratti
- 1st February 2009, 16:47
Thank you DarthV, unfortunatly the 16F84A is full as an egg and you cannot add even one extra byte. The controller accept TTL serial commands so if your radio device has serial communication capabilities you can feed the commands into the controller using this way.
I am working on MK2 version and I a using a more powerfull pic device, which could have some space available at the end (But who knows, I will tell you only at the end). Post some more details on what you want to do, perhaps I could see how to solve the problem.

Al.

tenaja
- 1st February 2009, 16:50
Would you mind sharing the PBP code for the hex file you've already shared?

aratti
- 1st February 2009, 17:13
Why not! I need to comment it before. Give me few days.

Al.

DarthV
- 1st February 2009, 21:03
Hi, guys....well let me describe better what the needs are, i have 2 PWM servo outputs, each one is driving each servo from left to right,..., with a 5V TTL logic level, movement from left to right is changing the pulse width from 1ms to 2ms, with 1.5ms at center position,....the movement is like 0....to...60 degrees minimum angle, or a maximum 90 degress !

Thanks

aratti
- 2nd February 2009, 11:57
DarthV, I have read your introduction to the problem. but you didn't write what your problem is.

Al.

DarthV
- 2nd February 2009, 14:09
Hi again, my problem is that i would like to use it but needs modifications and we only have de Hex code, so if you could do it for me that would nice, of course with the necessary cash amount for your work, if you wish so !

thanks

aratti
- 2nd February 2009, 15:43
Attached the PBP files in txt format. If you need to add more code then you have to change pic.
Suggesting pic 16f628 which has the same pinout but 4K of memory. In this case you have to add these two instructions at very top of the code.


CMCON = 7
VRCON = 0

This version is the latest so if you have in use the previous one replace it, with this one.
More torque, better homing and high precision also with 1 single step travel command.

Enjoy.

Al.

DarthV
- 2nd February 2009, 19:30
Thanks aratti ! :D

G.V

Archangel
- 3rd February 2009, 01:50
Hi Al,
1. Thanks for the nice code example / project, I will try it out !
2. Question: It appears you have set this up as a control for a home brew CNC project, just judging from the use of limit switch inputs, is that correct, and any issues using it for that?
Thank You
JS

aratti
- 3rd February 2009, 08:30
Hi Joe, the original idea was to have a handy and simple device to solve linear positioning requirement, and when you do positioning, you also need a zero point to start and limits security.

But since you can serialy network the controllers, you can also control two or three axis and have a small open loop cnc system. The only limitation is that you will have only point to point positioning or linear interpolation but not the circular. But for simple drilling tasks, for instance, this will be ok.

Nice to hear from you.

Al.

tenaja
- 5th March 2009, 04:11
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
- 5th March 2009, 12:20
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
- 20th April 2009, 18:05
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
- 21st April 2009, 10:30
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
- 22nd April 2009, 13:39
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
- 23rd April 2009, 16:13
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
- 23rd April 2009, 16:20
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.

aratti
- 24th April 2009, 17:43
There are no points to continue!

Al.