Stepper motor question
babinda01
Posts: 54
Hi Everyone,
I am about to embark on my first biggish project using the propeller, and have my first technical question.
I am trying to make for myself a CNC controller for up to 6 axis for a very weird machine I have built, and I want to output step and direction pulses from the prop. I have had a fair look around at what other people have done in regard to stepper motors and I am thinking of starting with some code posted by M.BROWN in about 2008 called AxisDriver[1], so in a nutshell I will be using one cog per stepper and the stepper code is written is assembler.
My question is.... how high a step rate (ie steps per second) could I reasonably expect the prop to produce????
Regards
Andrew
I am about to embark on my first biggish project using the propeller, and have my first technical question.
I am trying to make for myself a CNC controller for up to 6 axis for a very weird machine I have built, and I want to output step and direction pulses from the prop. I have had a fair look around at what other people have done in regard to stepper motors and I am thinking of starting with some code posted by M.BROWN in about 2008 called AxisDriver[1], so in a nutshell I will be using one cog per stepper and the stepper code is written is assembler.
My question is.... how high a step rate (ie steps per second) could I reasonably expect the prop to produce????
Regards
Andrew
Comments
I am by no means an expert but I was able to get my NEMA 17 unipolar stepper motor running about 600 steps per second using SPIN and one COG. I'm pretty sure you could do any speed you need in assembler. I have since switched to a dedicated controller and just use spin to send commands. Sorry no real help but I thought I'd share my experience.
Regards,
Fred
Thanks for your input.
I am wanting to achieve approx 200,000 steps per second, but I don't know if I am being unrealistic.
Regards
Andrew
Is this stepper motor unipolar or bipolar... or what?
How many revolutions per second will it be running?
How many steps per revolution is the motor?
Have you looked at the motor specs to see if it can go that fast and still produce any useful torque? If the motor performs 1 degree per step, then you're talking about a stepper motor running at about 555 revolutions per second. I'm no expert, but that seems extremely fast for a typical stepper motor that needs to do useful work.
As a comparison, a Dremel runs at maybe 35000 rpm, or about 585 revs per second. But Dremels don't use stepper motors for cutting operations.
I am actually using external drives which accept step and direction inputs.
Andrew
It also has modal and none modal functions (possibly not the right term) in the modal form your program waits for the move to complete, in the none modal the processor generating pulses does the move while your main program carries on.
I've attached it. It needs some work, the acceleration and feedrate numbers are a bit random but there is a bit of example code you can uncomment (need to change pin assignments). Try it on a motor not connected to a machine and it should work fine.
Graham
p.s. The assembly may make no sense but it is basically based on velocity, you have a regular sampling interval and over that time a stepper at a given frequency will have moved a given distance in steps, it is just a matter of keeping track and ramping frequency up and down as required. It is based on the way in which the geckodrive g-rex worked (now discontinued I think).
Thanks very much for your input, and thanks for the example code. I will have a play and see what I can achieve - I will keep you posted. I have got some code working on an Arduino that can read Gcode directly - Linear, circular and helical moves, and I can generate step pulses at a little over 35Khz, if I can get this working on the prop and increase my step rates significantly I will be very happy.
Thanks again for your help.
Regards
Andrew
I'm impressed. What sort of stepper motors are you guys running at 200kHz-1000kHz?
I submitted an object even as a relative beginner because at the time there was nothing there and I kept seeing requests in the forum. A member said I should post it to the Obex...so I did. It appears to be OK since it is being downloaded and no one has emailed me asking for additional help.
You can get step/direction based servo drives, if you have a high resolution encoder then pulse rates can be very high indeed. Generally belt driven systems with low force requirements such as laser cutters, plotters etc will also have high pulse rates.
Lardom,
I will post sometime once refined. Personally I am not interested in making my own stepper drivers as they are so cheap now so I use the propeller as the motion controller producing only step and direction signals.
Graham
Well then, I guess that explains why some of these controller chips boast such high stepper rates. I just thought they were bragging about overkill.
thanks for the explanation,
I decided to chime in with posting some code. Even if the code isn't finished yet.
I started working on this three years ago. Recently I picked it up again as
I got the mechanic with steppermotors of a mini cnc-mill from a friend.
This code uses the PropTerminal to communicate with a PC.
It makes intensivly use of textbased menus to control the propeller.
So it might be a template for that too.
You can download Propterminal from insonix
The website is in german but the propterminal manual is in english so no problem.
I coded an asm-driver that uses the bresenham-algorythm to drive TWO
axis at the same time in ANY X/Y-speed-ratio.
The asm-cog expects variables to be set and then waits for a start-command. Then the asm-cog creates the direction and step-pulses
for x and y-axis independently. The spin cog can do different things in
the meantime and/or wait for the asm-cog to finish.
Next step in this software is to implement a variable for steppulses speed and then
for ramping up/down. So this version can mostly be used to learn about the basic concept how to communicate between a asm and spin-cog and how
the bresenham-algorythm can be coded in asm.
Somewhere else I posted a PDF-file how the bresenham-algorythm can be
extended to three axis. (most of it is that you have more different cases
of direction-combinations (x+ y+ z+, x- y+ z+ x- y- z+ etc.)
Maybe Graham likes to combine this with his code that does accelleration
best regards
Stefan
ElectricAye - As Graham has already said, once you start using Servo motors it is very easy to get up to very high step rates, you consider a motor with a 4000PPR encoder doing up to 3000RPM - that is an huge step rate. Usually there is a divider of some type to divide the encoder count, up to a point this is ok but it will start effecting the machines performance if you go to far.
Thanks again for the input you guys have given - once I have something working I will post it for all and sundery to play with.
Regards
Andrew
Thanks for your input.
My biggest issue at this stage I think, is trying to work out the best way to attack the structure of the program. Initially I thought that I would have one cog per axis, but now I am not so sure this is going to work. My main problem is that I need to get all 6 of my axis interpolating, and if I have to bung all my axis into one cog to achieve this, it will effect my top end performance.
Anyway I will have a stab at it and see what happens.
Thanks again
Andrew
I guess that working with the bresenham-algorythm on six axis won't effect
on the topend speed too much. The step-pulses-loop runs through always
at the speed of the fastest axis. All other axis get their pulses derived from
the fastest axis. Me code uses a lot of subroutines to keep the code easy to understand. You can save execution-time if you re-code it withuot subroutine calls.
Another approach might be to use the hardware-counters. I'm not very familiar with them. But maybe the counters offer a mode that makes the counter pulse out a pulsetrain of a variable amount of pulses and then stop immediatly. Hm - that's really interesting gonna start a new thread for this question.
If you wrote interpolating all 6 axis. Do you mean all six axis have to move
in a synchronised way? Each axis at a certain speed-ratio to the main-axis?
As a short test of the maximum speed: if you reduce the delay-time
to a minimum and then just measure with an oscilloscope you can
measure the maximum-pulse-rate. Two ore more cogs can be synchronised
to each other. (Thanks again to Chip Gracey for the totally deterministic behaviour of the prop !)
By synchronising cogs - if I remember right - some guys speeded up the samplerate for digital signals up to 40 MHz!
best regards
Stefan
Andrew, I think it is possible to interpolate 6-axes with three cogs using my method however as I have not yet done two I am not sure how easy it is.
Graham
My code DOES use the hardware counters!
Graham
Give me a bit of time for the explanation, I'm rusty but it is quite straightforward when it comes down to it.
Graham
Stephan - Yes I would like all my axis to have the ability to run in a syncronised way. Realalistically I can't see more that 4 axis moving at the same time, but my issue is that I don't know which axis will be moving at a given point, so I need to make the system be able to interpolate all of the axis.
Graham - Are you suggesting that I should have 2 axis per cog i.e X & Y on one cog and Z & A on another cog and then if I need to move X,Yand Z I have those two cogs syncronised?
Andrew
My step-pulses-loop has about 40 commands. each command needs 4 clockcycles. each clockcycle is 12.5 naoseconds
results in 12.5*4*40 = 2000 nanoseconds = 500 kHz. Is this fast enough?
I know about a servo-control that has some kind of a programmable step-pulse multiplyer. This means the encoder on the motoraxle has 8000 pulses per revolution
but the controller can be programmed that each external pulse creates
200 internal pulses. Of course this means lower accuracy for positioning
but still high speeds at lower pulsefrequencies and a lot of torque as it is a servomotor in closed-loopmode and not a stepper-motor (which looses torque at high speeds)
best regards
Stefan
Yes 500Khz would be perfect. I worked out that in a perfect world I need 350Khz, but I was willing to compromise and set myself a minimum of 250Khz - so 500Khz is wonderful.
Andrew
200,000 SPS is a very fast value for steppers, even with micro stepping. I am in the process of building a CNC control (exhibitted at UPEC last year). I have been working on this for a couple years now and am still not finished.
While I suspect it is possible to achieve 200,000 SPS with the prop in software, there are many other factors that will limit your speed.
Mechanicals - can your machine handle that velocity?
Motors - can your motors handle that fequency?
Drivers - can they be switched that quickly?
Software - can you perform ACC & DEC smooth enough?
Steppers don't like high speed, rather they are happy at low speed so I would look to gearing to achieve the higher velocities. Or, if you can't gear it, look to servos to run at that speed.
Perhaps you could post some more details about the machine which might be beneficial.
I would post my code to help you, but I am no where near the point of being able to explain what I have accomplished so far. Most of what I have works, but there are some gremlins I have been fighting with for a while now. Furthermore, I am only targeting 4 axes and at present have only logic for 3 total axes (2 simulataneous).
Chris
did you ever know the bresenham-algorythm?
in the attachmend is a description how it can be extended for three axis
moving 3D.
Most of it is to distinguish between different cases for the spatial direction.
(can you please comment on the qualitity of the sentence above. As this sentence was translated by google. To me it sounds perfect but is it real perfect?)
I'm doing the same thing with a real small cnc-mill.
(tiny motors only good for surface scratching or engraving.)
best regards
Stefan
for example, say from 0 to 30 degrees takes 1200 steps, you would also then think that from 30 to 60 degree would also take 1200 steps. You will find out that this is not the case.
The linear algorithm has a similar problem, however, because it is a bit easier to understand and work with, I was able to work around that problem.
If any of you math wizards figure out a way to get consistent results, I sure would like to hear from you.
Chris
If you consider what you've done so far to be unsatisfactory then I have to ask how far are you from a commercially viable design?
Thank you very much for the compliments - much appreciated!
You are correct, two different types of micros: AVRs (Atmel) and Propellers (parallax). I use two prop chips:
1 for Keyboard, mouse, and VGA output
1 for motion control which is step & direction output and home/limit switch monitoring
The two AVRs handle the tasks of:
The 2560 is used for editing and interpreting the CNC program
The 644P is used as the motion planner (or profiler)
Getting them all to play nicely and efficiently is a challenge in itself;-)
The "problem" I have is the exacting performance I am trying to achieve. I have worked with CNC machinery since the 70s. Througout the years, I have seen some very good controls (and some really bad ones). Even though I know my control will never be brought to market, I still want it to perform robustly. So, my basis for comparision is to industrial CNC controls that cost as much as a small car. I know i will never achieve that level of power and features, but I have fun (and sometimes not so much fun) trying;-)
So, while it works and works good, it just isn't "good enough" yet. I am on my 3rd or 4th attempt on the motion control portion of the control. The last attempt was with the Bresenham algorithms which worked really good - up to a point. Even if the latest idea works great, I probably still won't be done.
The whole point of the control was to learn about electronics, expand my understanding of CNC, and challenge myself. Thus, the meaning of RIAM CNC on the you tube site: Research In Automated Motion. At some point I hope to be able to share my findings, but right now I am caught up in the game of researching.
Thanks again,
Chris
Thanks for your input - I was actually inspired by your machine to start this project.
I am actually using AC servos on my machine, but I am running them from step and direction signals - and that is why I used the reference to steppers. I am well within the specs of the motors at running at these speeds and they can handle it fine.
My machine is a high definition plasma cutter. I can cut with the plasma in 6 axis X,Y,Z (Linear axis) and A (Rotary axis for pipe & tube) and B & C as rotary axis on the head so that I can bevel cut plate.
Can you please tell use why you opted for the AVR chips for other tasks, rather than using another prop?
Regards
Andrew
I have used the linear bresenham-algorythm at the company I was working some years ago very succesfully. I haven't used the circular version yet.
In the PASM-code I posted I tested code for several XY-ratios even "strange" ratios like 29 steps in x and 6 steps in Y and counted every single step.
These tests were successful. Then I made a test with driving both axis for
some 10000 steps at different ratios but without controlling every single step. From just looking at the motion without counting each step it looks OK. So from this you can see I' haven't finished my own testing yet.
For the circular version I assume the algorythm works if you get different results for 0-30 degree 30 to 60 degrees I guess it is a softwarebug.
How about coding a testversion that draws a circle on a screen for easier debugging what is happening?
Hey! this would offer the oportunity to draw the movements on the screen in general! This owuld be a great thing to simulate the movements before
really executing them (and maybe crashing the tool)
Do you mind sharing the code you have programmed?
My first quick guesses are
1.) maybe your algorythm-code always starts at 0 degrees even if you just want to move from 30 to 60 degrees.
2.) In the linear bresenham-algorythm sometimes X is the "leading" coordinate sometimes Y is the "leading" coordinate. Depending on the X-Y-ratio of the X/Y-steps
I assume in this point there it is the same in the circular version. So the
different amount of steps maybe results from Y-axle should be the "leading"
direction but you are using X-axle as the leading one.
These are only quick guessings into the fog. If you have checked these things doubled please excuse me for asking that.
I haven't used any of the graphic objects so far. Somebody who has experience with the graphical objects:
Is there a method for drawing circles on the screen?
Is it an implemetation of the circular bresenham algorythm?
or does it use the sine and cosine tables of the ROM?
Can somebody say something about the acuracy of the calculations?
With the ROM-sine/cosine-tables:
can you get still exact X/Y-values for a BIG circle on a high resolution that has let's say 1.000.000 steps to move 360 degrees?
I know asking questions is much easier than answering them. But maybe
out there in the propeller-space there are some experts that have already
done it and can easily answer these questions.
Maybe we can divide the researching on this to several people one examining the ROM-sine/cosine-tables another examining the circular
bresenham-algorythm etc.
What do you think about that?
best regards
Stefan
EDIT additional thoughts added:
remark at the beginning: I assume that the reader is somehow familiar to the bresenham-algorythm as I'm using
"technical terms" used in the algorythm. So if you are not familiar with the bresenham-algorythm some parts of
my writing will be difficult to understand.
As far as my analysing and thoughts have gone until now I think controlling more than two axis can be done this way:
The distance in steps of each axis has to be calculated.
Then you have to analyse which axis has the biggest distance.
if you always compare the biggest-distance axle as "X" with any other axle as "Y" the "slope" of the second axle is smaller than 1.
And the Bresenham-algorythm can be applied to these two axis. For the 4 other axis it is the same. You only get different values for the slope.
So all axis have their own Y-value and errorY-value (maybe called Y1, Y2, Y3, Y4, Y5)
For two seperated axis you are handling with X and Y1 or X and Y2 etc. Each axis has its own variables. Instead of dealing with each pair of axis
one after the other you have to do it for all axis at the same time. As the slopes are different for each axis but each axis has its own variables
each axis will get the next step-pulse at its time but always the right time (controlled by its slope-value)
The bresenham-algorythm needs to know in which octant (1/8th part of the XY-area) the movement lays in.
Depending on the octant X and Y-values have to increase or to decrease. I guess if the error-variables are multiplied with sign-values +1 or -1
the number of if-conditions that check if Y1, Y2, Y3 axis has to be stepped forward/backward can be reduced to the half.
Coding this is mostly a matter of beeing diligent and checking the software-calculated values by calculating them by hand in each pair of
possible X-Y1, X-Y2, X-Y3 combinations and for each octant.
I suggest to code it in that way that you have a virtual X-axle and a Y1-, Y2-, Y3-, Y4-, Y5-axle and then
do some kind of mapping the REAL axle1, axle2, axle3, axle4, axle5, axle6
to
X and Y1, Y2, Y3, Y4, Y5 for the "stepping"
and then
mapping back to axle1, axle2, axle3, axle4, axle5, axle6 to get each pulsetrain directed to the right axle.
By this way all axis will be synchronised to each other as all axis get their pulses derived from the virtual "X"-axle
which is always the one with the biggest distance.
hm - not difficult but a lot of work
Andrew,
Yes, I see now that you servos and drives can handle that level of performance. However, let's look at some math to see what you are trying to achieve...
Assuming 1 step = .0001" inches
200_000 * .0001 * 60 = 1200 inches per minute. Do you really need to move that fast? Ofcourse if the resolution of your encoders is better than .0001" (translated to linear), then the resulting top speed is reduced.
Now let's look at it from the opposite side of things, what can be done by the prop @ 200 Khz. motion clock frequency...
80_000_000 / 200_000 = 400 Prop clock cycles
400 / 4 = 100 PASM instructions (4 clock cycles per instruction)
So, in 100 PASM instructions, you have to do everything required to make the next step. Luckily, the Prop's 8 cores can share the workload but it still can't do everything in that time frame.
Even at my goal of 100 Khz motion clock frequency, doing everything I want isn't possible in the Prop.
The above should help provide you with some guide as to how little time you have to accomplish tasks. This is in part of why I have 4 different micros.
I selected the Mega2560 for its large storage capacity for Code and data. I even added memory expansion to that chip. This chip is really the core of the system. Depending on which mode of operation the machine is in:
EDIT MODE allows you to edit the program. The CNC program resides in memory (XRAM) and the editor operates very similar to Notepad. I started out with a line editor, hated it so I recoded that. It now works pretty good. As you can image, there is a lot of code in creating an editor.
AUTO MODE allows the CNC program actually run. Each line has to be interpreted and parsed. While the CNC program is executing, I am updating the screen with the current block data and updating the position display as fast as possible without bogging the system down. These tasks consume nearly all the resources of this chip and I still have not converted the user coordinate and velocity data into step & direction units. This is where the next chip (Atmega 644p) comes into play. It takes the user coordinate data, breaks that down into step units for positional data and velocity data. In those units, I then work out the details for what I want regarding acceleration / deceleration etc. Once that is all computed, I pass the refined data into the Prop chip which then performs the tasks of: creating the step & direction signals, Controling velocity, monitoring limit switches, monitoring positions from linear scales using the quadrature encoder object.
MDI MODE allows for single use commands to be passed into the parse routines as described in AUTO MODE. Currently this is "broke" and I need to fix this.
JOG MODE allows for manual movement of the axes and for inputting offset data etc. While jogging at first seems very easy, there is a lot more going on than you would think. Anyway, there is a lot of code required for the user interface etc.
As for why the Atmega specifically, well the first CNC controller I did was a hybrid PC & micro controller CNC controller. On that one I used the Atmegas and became very familiar with them. When I reached the limitations of of what I could do with the Atmegas I then sought out an alternative chip to help with CNC performance (max speed) which is how I ended up with the Props. At first glance, the prop appears to be much more limitted than what it actually is. By looking through the manual you get the impression that memory is stricly limitted and data types are limitted etc. Obviously, this is not the case.
Wow, that turned into a thesis but hopefully it will serve as a reality check with what you are attempting to do.
Chris
The problem with Breseham & circles is not as you think based on my description - sorry. To describe it a bit more...
The algorithm is good and accurate to create the geometry - proper number of steps and proper directions. Being that it was originally created for computer graphics, you can see that it is being cross-applied to motion control. Motion control requires the next element of velocity to be added to that routine. Basic velocity is fairly easy to add to it, just create a dwell between steps. But when you start to think about acceleration and deceleration, you have to know where you are and how many steps to go to finish up. This is where I found the problem...
Thinking of an arc or circle in terms of circumference, you would expect that any angular segment of a circle would require the same number of steps through the loop. But this is not the case. Using my example before...
"for example, say from 0 to 30 degrees takes 1200 steps, you would also then think that from 30 to 60 degree would also take 1200 steps. You will find out that this is not the case."
Let me rephrase that with:
for example, say from 0 to 30 degrees takes 1200 times through the loop, you would also then think that from 30 to 60 degree would also take 1200 times through the loop.
Because I have found this variance in the number of loop iterations depending on the angular segment being worked on, I was not able to accurately apply deceleration. In some places you start decelerating too soon, in others you start too late.
I am re-thinking this routine right now and suspect I might be able to look at "Distance to go" in another way, rather than loop cycles to go, I could look at the geometry. At first this appears to seem easy, but with circles, crossing quadrants and axis reversals being part of the continuos motion creates many other problems. While i noodle on this problem, I am also working on plan D or perhaps I am up to E now :-(
Chris
Thanks heaps for your help. I think I need to get my ideas straight in my head about what I am wanting to achieve (and how I am going to achieve it).
I have used a few of the "micro" based CNC controllers on the market like DeskCNC which uses a single PIC chip, as well as the NCPod from the same chap, and one from Rutex here in Oz. What all of these have in common is they do the GCode/Command processing on the PC which then seems to send packets of position data every 1mSec. Which is a totally different kettle of fish than trying to do all of this on a Prop or even a Prop/Micro combo. Hmmmmm.
If you are not using Breseham's algorithm, are you using a Cordic method for interpolation???
Regards
Andrew