View Full Version : Stepper motor question

11-24-2010, 11:54 PM
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????


11-25-2010, 12:29 AM
Hey Andrew,
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.


11-25-2010, 12:39 AM
Hi 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.


11-25-2010, 02:06 AM
I am wanting to achieve approx 200,000 steps per second, but I don't know if I am being unrealistic.

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.

11-25-2010, 04:42 AM
I am actually using external drives which accept step and direction inputs.


Graham Stabler
11-25-2010, 11:29 AM
My object uses the counters and can produce step rates up to many Mhz with trapizoidal motion profiles, at the moment however it does not do multi axis synchronization. I'm hoping to do some work on it soon so that you can control two steppers per cog and synchronize between them to allow for typical CNC type moves. If you just want to drive one stepper at a time then you can use one cog to run as many as you like.

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.


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).

11-25-2010, 12:54 PM
Hi Graham,
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.


11-25-2010, 02:47 PM
My object uses the counters and can produce step rates up to many Mhz with trapizoidal motion profiles...

I'm impressed. What sort of stepper motors are you guys running at 200kHz-1000kHz?

11-25-2010, 03:35 PM
Graham Stabler, thanks for posting your code. Please consider submitting it to the Obex. Stepper objects are still underepresented there. I, for one believe a stepper is the ideal digital motor. I also would like to see a microstepping object there.
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.

Graham Stabler
11-25-2010, 05:06 PM
Electric eye,

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.


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.


11-25-2010, 05:30 PM
Electric eye,

You can get step/direction based servo drives, if you have a high resolution encoder then pulse rates can be very high indeed. ...

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,

11-25-2010, 10:15 PM

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 (http://www.insonix.ch/propeller/prop_term.html)

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


11-25-2010, 10:19 PM
Hi Guys

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.


11-25-2010, 10:30 PM
Hi Stefan

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


11-25-2010, 10:46 PM
Hi 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


Graham Stabler
11-25-2010, 10:49 PM
Stefan, my approach is fundamentally different at it works with frequency rather than by considering each step one at a time, so I can't add it to your code or your code to mine.

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 Stabler
11-25-2010, 10:52 PM

My code DOES use the hardware counters!


Graham Stabler
11-25-2010, 11:06 PM
The counters are used as a numerically controlled oscillator and that is all. There is no way to make them work in a smarter way than that but it is perfect for doing motion profiles.

Give me a bit of time for the explanation, I'm rusty but it is quite straightforward when it comes down to it.


11-25-2010, 11:26 PM
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?


11-25-2010, 11:42 PM
I made a quick estimation about the execution-speed

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


11-25-2010, 11:51 PM
Hi Stepan,
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.


11-26-2010, 12:13 PM
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).


11-26-2010, 04:19 PM
Hi Jim,

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


11-26-2010, 06:03 PM
The problem I found with the Bresenham algorithm deals with acceleration and deceleration. You will notice that if you test these routines, you will find that it does not create an exact number of steps based on the discrete motion being programmed. In other words, for the circular routine, you will see that the algorithm outputs many more steps than what is required to go around the circle. Further more, depending on where you are on the circle, the number of steps is different.

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.


11-26-2010, 07:24 PM
Chris D, I thought the cnc that you designed was absolutely amazing. I've seen the videos. I believe you used two different micros. (Atmega/Propeller?). I think that makes you an authority on the subject.
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?

11-26-2010, 09:32 PM

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,


11-26-2010, 10:39 PM
Hi 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?


11-27-2010, 09:40 AM
Hi Chris,

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


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


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

11-27-2010, 11:34 AM
Hi 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?



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.


11-27-2010, 11:52 AM

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 :-(


11-27-2010, 12:53 PM
Hi 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???


11-27-2010, 01:07 PM
Yes, most other offerings out there are PC based using either the parallel port for the interface or some other intermediate device providing the real-time signals for the interface. This is a bit easier than trying to do everything on micros. As you know, micros are no where near as fast as micoprocessors which run MUCH faster and perform floating point math efficiently.

Currently I am running bresenham, but the previous attempt was to use one cog per axis so I had enough time to handle all the calcs. The problem with that is coordinating the cogs for precisely synchronized motion - never got that as good as I wanted.

My next direction is being figured out right now. I know I will put all of the step & direction outputs into one cog to help insure accurate synchronization. I have a few other ideas I have to work out but these require lot's of time to think through. Having just started a new job, my "think time" is not as clear as I would like, but that is life.

The other thing that just came up that could help a lot is that FP32 object someone posted. That appears to be very efficient which could help me out substantially if I can figure out how to exploit its power.


11-27-2010, 01:52 PM
Hi Chris

Is Floating point an issue? I "think" I have a way around it by using counters. It worked for me about 10years ago on an AVR Mega32 I can's see why it wouldn't work here.


11-27-2010, 02:24 PM

Sorry, I can't read 'C' very well (or at all for that matter). I suspect that the FP32 object that was posted should be fast enough to do what I need and seeing as I have 1 COG to spare, it should do the trick.

I will have to post in that thread some questions about it though so that I understand it better.



11-27-2010, 07:50 PM

to apply accelleartion and decelleration I coded it this way:

through acc the time to wait until the next pulse has to be created
gets shorter from step to step.

It starts at a frequency the steppermotor can handle from 0 rpm and stops
at a max frequency.

With deccelartion it is simply the opposite way. The waittime from pulse to pulse gets longer down to the frequency the steppermotor can handle to
go from low-freq to 0 Hz within ONE step.

The waittime-values for acc and dec are stored in an array of 100 eelements.
Let's use easy values for explaining it:
waittime(0) = 10 msec
waittime(1) = 9 msecs
waittime(2) = 8 msecs
etc. etc

Now my my stepout-methods divides the complete way into three parts
1.) acc
2.) hold on max speed
3.) decc

(if the complete amout of steps is lower than 200 example 120 steps you go up acc for 60 steps and down for 60 steps)

the loop that creates the pulses has a waitcommand to create the applied frequency.
Inside the loop a counter counts up the steps and this step-variable is used as index for the waittime-array

with the example-values from above:

first loop
variable step has value 0
wait(waittime(step)) which means waittime(waittime(0)) = wait(10msecs)

second loop step has value 1
wait(waittime(step)) which means waittime(waittime(1)) = wait(9msecs)

third loop step has value 2
wait(waittime(step)) which means waittime(waittime(2)) = wait(8msecs)

etc. etc.

The complete amount of steps is divided by 2 to get the two halfs

first half for acc and hold max-speed

and second half for max-speed and decc

the loop contains a condition
if step > maxWaittime
wait(waittime(maxwaittime)) which means wait(waittime(100) which is the max-speed

and you are done about acc and decc always automatically in the right amount of steps.

Of course creating an array in PASM is a bit more difficult than in spin
but not that much more difficult.

best regards


11-27-2010, 10:39 PM
Hi Stefan,

Thanks for the explanation. I too have tried that method in an earlier attempt and found there are two problems...

1) You are adjusting the velocity by changing the wait time between steps. This results in an ever increasing ramp up to speed. It is actually a curve that is not going the good way. The method you describe will work when you are well within the limits of the mechanicals.
However, if you are pushing towards the limits, the chance the stepper motor stalls out increases dramatically. Ideally for steppers, you want an S curve ACC & DEC but this is much more difficult to program than a trapzoidal ACC & DEC. In the example you described, you have neither. Acceleration and Deceleration has to be time based and not based on position. Time is the constant, 10 mSecs is alway 10 mSecs so acceleration that is applied in timed intervals becomes a constant increase (stright line ramp up/down). However, your time between steps keeps getting shorter with each step and if you keep subtracting time from each step it is like a runaway snowball growing exponentially. Again, I must clarify, what you describe will work, it is not as ideal as I would like.

2) You motion planner method seems to indicate that every move will start from zero speeed, accelerate up to run speed, then decelerate back to zero speed. This is okay for point-to-point positioning, but in practice, it is not good for CNC machining in metals. This start-stop motion causes tool chatter at the vertices between movements. CNC machines have a much more fluid motion, wherein the next moves starts before the current moves is completed. Yes, it causes corner rounding which is acceptable in many contouring cases. When it is not acceptable, you would use the CNC feature called exact stop check (G09 or G61) to cause "stops" at every vertice.

Your thinking about breaking up the motion into 3 phases is spot on though. The process I am developing right now is doing that too. In all my previous attempts, I command the motion as a "whole unit" and allowed ACC and DEC to occur dynamically, thus breaking the motion down into the 3 phases. This method works pretty good but it can easily get out of control. So on my latest attempt, I am breaking the motion into the 3 phases in the planner before I run the motion. I suspect this will allow me to synchronize the 4 axes better than previous attempts. The down side is I won't know for a month or two as I just do not have the time to keep working on it.

I must say, this thread is getting very interesting and indepth. I sure hope anyone that is thinking about creating a CNC control is giving this a read.


11-27-2010, 11:38 PM
Hello Chris,

I must admit that your knowledge about CNC is a lot greater than mine.
My experience is based on diamond engraving. As you have mentioned it now
it is really obvious to me that complete stops are causing more problems with tools that are turning around an axle than with a still standing diamond peak.

Anyway I agree the thread becomes more and more interesting.
Interesting challenge to code a motion-planner that smoothens the direction changes. I have an idea how edge-rounding can be avoided for a part of all possible movings. If the motion-planner adds a "mill out of material" movement
and start a "mill into material again" movement this will avoid bad (and
chattering) forward to turning speed ratios. Of course for the cost of more
time it needs to move the additional way.

So a good motion-planner would have to take care of each next movement
and do the calculation of acc / dec based on the angle-difference between
the actual direction and the next direction.

Small angle only a few decceleration and acc after changing the direction.
Big angle more decceleration and acc after changing the direction.

how much acc/dec is needed depending on the angle would be evaluated through tests in real metal.
Or as second best in the air to have the inertia of the machine itself.
Maybe this is even better because cutting metal is always like a brake.

As the propeller offers 8 cogs that can work in parallel I suggest one cog is just creating the pulses based on a set of parameters.
So this cog needs only a little time to load these values and then executes stepping-loops.

Another cog will do all the calculations like amount of steps acc / dec values allowed corner-rounding based on
tool-overlapping from turn to turn etc.

As you want to push the machine to its limits I guess servomotors will pull the limits pretty far beyond what a steppermotor can do. I know a manufacturer of small servomotors and control-units.

ecostep motors (http://www.jat-gmbh.de/engl/produkte/motorpalette/00_motorpalette_neu.html)

The control-unit for one motor for currents up to 6Ampere is around 300 Euro. I don't have prices of the motors. I have worked with these controls.
The have parameters to adjust almost everything you would like to.
The control has a position, speed and acceleration-controller which are working hand in hand or maybe as one above the other. So all in all a PID-control where you can adjust P, I, D and even more parameters
each to his own value to adapt to almost every mechanical situation
like different inertia or "stiffness" of the mechanic to be as fast as possible without making the system swing for and back.

If I remember right you can even adjust the allowed edge-rounding for direction changes. An interesting question is how much motion-planning these servocontrollers can do for TWO or more axis. To find the optimum between maximum-speed and edge-sharpness. They have a serial and a CAN-Bus interface which can be used to reconfigure parameters on the fly.

I'm not a big expert about servo-controls on the market but I guess this is pretty muc

11-28-2010, 11:08 AM
The motion Planner is a very key element in the CNC system. It is what creates a smooth flowing contour which results in efficient machining and reliable operation.

Executing the step & direction output is fairly simple by comparison, create a consistant pulse stream for all the axes based on a common clock source to keep them synchronized.

You concept of overshoot, then come back to the cut would be very difficult to impliment and certainly inefficient. In the case of milling, the tool can be cutting on either side of the programmed path. From our perspective, we can see which side of the path the part is on, from the CNC's perspective it doesn't know. The only way you could perform the overshoot and cut back in is to also use the feature tool radius compensation (G41 or G42) which compensates for the tool's radius and offsets the tool's path. But that then adds another level of complexity to the tool path. The fun part of working with the PROP chips is to figure out ways to get all the tasks done in the required time by dividing up those tasks across multiple cores - a luxury not offered in most other micros.

All in all, creating a CNC control that mimics industrial controls is very challenging. You can certainly get away with a lot of "kludges" if performance isn't being chased, but in the end there is a reason why industrial controls cost so much - a lot of engineering goes into them.

While I like to mess around with steppers, servos are the king in CNC. Probably 99.9% of all industrial CNC machines use servos. I suspect there are good engineering based reasons for this ;-)


11-29-2010, 12:10 AM
Hi Guys,

I have been thinking a bit about what I am wanting to achieve, and how I am going to achieve it (Thanks to Chris for his experience here). So this morning I thought I would procrastinate a bit (I am supposed to be doing a customers job).
I have hacked the EMC GCodeCompiler a bit so that I can read in a complete gcode file (on Windows) and then output 6 axis positional commands at an interval of 1mSec per reading i.e:

motion id 11
0.000000 0.000000 -0.039967 0.000000 0.000000 0.000000
0.000000 0.000000 -0.042104 0.000000 0.000000 0.000000
0.000000 0.000000 -0.044299 0.000000 0.000000 0.000000
0.000000 0.000000 -0.046550 0.000000 0.000000 0.000000
0.000000 0.000000 -0.048858 0.000000 0.000000 0.000000
0.000000 0.000000 -0.051224 0.000000 0.000000 0.000000
0.000000 0.000000 -0.053647 0.000000 0.000000 0.000000
0.000000 0.000000 -0.056126 0.000000 0.000000 0.000000
0.000000 0.000000 -0.058662 0.000000 0.000000 0.000000
0.000000 0.000000 -0.061256 0.000000 0.000000 0.000000
0.000000 0.000000 -0.063907 0.000000 0.000000 0.000000
0.000000 0.000000 -0.066614 0.000000 0.000000 0.000000
0.000000 0.000000 -0.069379 0.000000 0.000000 0.000000
0.000000 0.000000 -0.072200 0.000000 0.000000 0.000000
0.000000 0.000000 -0.075079 0.000000 0.000000 0.000000
0.000000 0.000000 -0.078014 0.000000 0.000000 0.000000
0.000000 0.000000 -0.081007 0.000000 0.000000 0.000000
0.000000 0.000000 -0.084056 0.000000 0.000000 0.000000
0.000000 0.000000 -0.087163 0.000000 0.000000 0.000000
0.000000 0.000000 -0.090326 0.000000 0.000000 0.000000
0.000000 0.000000 -0.093547 0.000000 0.000000 0.000000
0.000000 0.000000 -0.096824 0.000000 0.000000 0.000000
0.000000 0.000000 -0.100159 0.000000 0.000000 0.000000
0.000000 0.000000 -0.103550 0.000000 0.000000 0.000000
0.000000 0.000000 -0.106999 0.000000 0.000000 0.000000
0.000000 0.000000 -0.110504 0.000000 0.000000 0.000000
0.000000 0.000000 -0.114067 0.000000 0.000000 0.000000
0.000000 0.000000 -0.117686 0.000000 0.000000 0.000000
0.000000 0.000000 -0.121363 0.000000 0.000000 0.000000
0.000000 0.000000 -0.125096 0.000000 0.000000 0.000000
0.000000 0.000000 -0.128887 0.000000 0.000000 0.000000
0.000000 0.000000 -0.132734 0.000000 0.000000 0.000000
0.000000 0.000000 -0.136639 0.000000 0.000000 0.000000
0.000000 0.000000 -0.140600 0.000000 0.000000 0.000000
0.000000 0.000000 -0.144619 0.000000 0.000000 0.000000
0.000000 0.000000 -0.148694 0.000000 0.000000 0.000000
0.000000 0.000000 -0.152827 0.000000 0.000000 0.000000
0.000000 0.000000 -0.157016 0.000000 0.000000 0.000000
0.000000 0.000000 -0.161263 0.000000 0.000000 0.000000

These coordinates are in milimeters (sorry I am an Aussie). Because they have been precompiled, they are taking into account ramping up and down, and constant velocity contouring (I think - I haven't plotted the points yet) arcs etc etc.
I am now thinking that this may be the better way to go - precompile my gcode on the pc - send the info to the prop via ethernet - store on an sd/compact flash card - run, pause, stop, overrides, limits etc etc can easily be monitored by the prop. Pausing/Feed holding will be my only issue, but I don't think it will be to huge of a job to figure out.

What are your thoughts????


11-29-2010, 10:19 AM

If I wasn't so stuborn and bullheaded, I would do it.

Years back I wrote a program that would graphically plot the tool paths for CNC programs. In order to get the performance I wanted, I converted the CNC Code into an intermediate code, then plotted that intermediate code. It was very fast and efficient.

You are right, working out the details to make this run won't be too bad. The only "tricky" thing is that you have to create a variable clock source. This variable clock source is how you handle feedrate override and feed hold. Here is how it will work...

Select a frequency, say 50kHz as your basetime, this would represent 100% feedrate. If you turn up the feedrate override to 200% your basetime is now 100kHz and likewise if you turn it down to 10%, your basetime is 5Khz, and 0% is zero clock output. This is how you control the velocity with the override - simply by changing the time element. For feedhold, you would ramp down the timebase to zero (simulating a deceleration) and then ramp the timebase back up upon cycle restart. The same is true for single-block operation.

Before all that can work, you have to take those small linear movements, determine their "size constant" or "Time constant" and work out a frequency that will create a motion in the correct period of time. I am not sure what EMC is doing in this regard. It could be creating small linear moves that are 10 discrete positions "size constant" or it could be creating small linear moves that are 1 millisecond worth of motion "time constant". I would wager a guess that it is a time constant interval.

That should get you going with some thoughts to consider and I hope it helps.


Ahhh, I just re-read your post and realized you already determined that it is a time constant data block - that should be a lot easier to work with!

11-29-2010, 02:25 PM
@Chris_D, Why do high end CNC's use servos instead of steppers?

11-29-2010, 03:49 PM
I'm not aksed but I like to answer:

Servomotors can be driven on very fast RPMs and still have a lot of torque.
Servomotors have an encoder that gives a very accurate feedback about
the motorspeed and angleposition of the motor-axle

steppermotors loose torque with increasing rpm

steppermotors DON'T have a feedback about speed and angleposition
Of course you could add an encoder to a steppermotor but then you are
half way to a servomotor with the disadvantage of loosing torque at high rpms.

best regards


11-29-2010, 04:43 PM
StefanL38, Thanks for replying. I always thought a stepper was the best 'digital' motor because you could count steps without adding an encoder. In addition, unlike a servo, you could remove power without losing position.
Please tell me what kind of 'rotational' servo I need. I modified a servo by removing the 'notch' and replacing the potentiometer with two equally matched resistors. I controlled speed with PWM. I still need position.


11-29-2010, 04:56 PM
Hi Larry,

can you please tell details what you want to do "in the end".

Which motor fits your demands best depends highly on what you want to do.

Without this details I could only give a quarter professional overview which
motor has which advantages / disandvantages.

If you tell us what you want to do in the end you open the oportunity that
more solutions can be found and their pro's and cont's can be discussed.

I have experienced as soon as the whole thing is known sometimes
complete different but much better (cheeper, faster, easier) fitting solutions can be found.

As long as your maximal demanded torque stays below what a certain
steppermotor can hold/drive - in all situations -
a steppermotor is a good solution because
you don't need extra effort for encoders to keep track of the position.

So please tell us what you want to do in the end

best regards


11-29-2010, 05:29 PM
I designed and built a programmable slider for my camera. My other hobby is taking 3D lenticular pictures. I used a stepper and it is perfect.
For my next project I may work on a turntable that will turn my TV to face me. I can do it with a stepper but servos are easier to find and they are stronger.
The other reason is that I have motors with quadrature encoders and standard servos that I want to experiment with.

11-29-2010, 05:39 PM
Maby I have to clarify what I mean when talking about servos.

With servo I meant a DC-Motor with an encoder and a servo-control-unit
which realises that the DC-Motor can turn just a 1/100 degree or 3,8 rotations or whatever - by the help of the encoder on the motoraxle.

Do you mean servo in this way? Or do you mean with servo a "model-servo"
these tiny little things used in RC-modelplanes, RC-modelcars etc.?

So for your projects what rotational speeds and accuracy do you need for them?

best regards


11-29-2010, 05:53 PM
I don't require anything close to the precision you need for a CNC. The Bresenham algorithm is beyond me. From what I'm seeing I can probably accomplish what I want by learning to program my quadrature encoder.

I hope I didn't hyjack this thread. Thanks


11-29-2010, 06:02 PM
No I don't think so

If you want to discover yourself how quadrature encoders work
and how a program has to be to read them that's really OK.

If your main goal is to realise the project you could do

a search in the obex for keyword quadrature (http://obex.parallax.com/objects/search/?q=quadrature&csrfmiddlewaretoken=675621027132a19b1927c2aa208ba5 fd)

and find some things already coded.

best regards


11-30-2010, 10:51 AM

Stefan answered already but to help add some clarity here is a bit more about why servos are used over steppers...

Servos have an encoder which is used to provide velocity and positional feedback to the drive system. The drive can then use that feedback along with motor current draw to determine what is actually happening during the motion. This creates a relativly closed loop monitoring system. For steppers, you have zero feedback - it is completely blind.

Consider the comparison to a person walking...

You are walking with your eyes closed - how do you know where you are? The only reference in position you have is your estimate that if you take 400 steps you should be 400 steps away from where you started. What if you sumbled and skipped a step, would your destination be accurate at the end of the walk?

During the same walk, you have to arrive exactly 1.252 minutes later. Without velocity feedback you may have slowed down because of the hill you walked up required more effort. The result is you arrive .3 minutes too late.

Continuing this thought, what if the hill you tried to climb up was so steep you didn't have enough power to take the next step? Do you want to keep trying and fail or should you trust the feedback from your legs saying you are about to stall so stop gracefully?

Steppers are wonderful motors and I love playing with them. They are economical, their drives are economical, their interface (via the drives) is very simple, they don't require any maintance, but they are stupid. They only TRY to do what you tell them to do and if they fail in doing it, they won't tell you anything.

So, now let's see how that works out relative to industrial applications and the reality of business....

Your CNC lathe has stepper motors. It is very accurate in testing, you have the machine designed and setup to operate well within the limits of the motors. It has produced many good parts for months / perhaps years. Now you are machining a critical component for a jet engine - a bit tougher material than you normally have machined. Your trustly "blind" machine has done you good in the past so you trust it to faithfully machine this critical part for the jet engine. But, at some point during the machining, some chips bound up on the cutting tool causing the stepper to skip a few steps which caused all the remaining dimensions to be off and the resulting part is out of spec. 18 months later, there is a breaking news story, a plane crashed with 300 people on board, all died. After the NTSB investigation, they found that the cause of the plane crash was a faulty component in the engine.

For another example, you CNC grinder uses steppers. It has been a good machine that faithfully produces accurate parts. Its a big one too, it has 24" diameter wheels that are 4" wide and the spindle runs at 1400 RPM so it is fast! One day after months of a long production run, the grinding wheel attepts to retract away from the part so the part can be changed. However, swarf has built up on the slide and the axis stalls out and stops short of the retract position. The operator changes parts, presses cycle start, and that was the last experience of his life. What caused his untimely death was an exploding grinding wheel. The reason the grinding wheel exploded was the CNC system had no idea the axis never retracted completely - it just assumed it did. Well, with that assumption, the next move command has the grinding wheel moving at full speed towards the part. Being that it was closer than expected, the wheel crashed into the part and exploded with tremendous force.

Feedback systems are critical elements that cannot be underestimated. If you have never worked in manufacturing, the two examples above might seem a bit extreme. However, I can assure you they are certainly well within the bounds of reality.

As mentioned by one of the other posters, the encoder on a servo can be of great precision, many counts per revolution. The highest number of counts i have seen on a rotary axis is 1 million counts per revolution. This allows for very accurate positional feedback. However, in some cases, even servos do not provide for enough feedback to truly close the loop. Even though the enoder provides feedback to the rotary position of the motor, it does not provide you with feedback of the actual slide. All mechanical devices have clearances to allow the moving components to slide or move. This is "Slop" in the mechanical drive system which results in slight miss-positioning - usually < .0002". However, depending on the part being machined .0002" (which is 1/15 the thickness of paper) can be a country mile. So, for very high precision applications, another encoder is added to the feedback loop. This encoder is not rotary, rather it is linear, but it works on the same principle as a rotary encoder. The actual scale portion is made up of glass which is thermally stable and therefore maintains its accuracy well. If you have ever seen a digital caliper, it works on a very similar principle. This type of scale is connected to the machine base/slide and measures the physical movement between the two components providing near-perfect feedback of position.

I hope that the information above sheds some light onto why servos are better than steppers. It actually doesn't have much to do with the units themselves but rather their application in industry and the seriousness of their role in manufacturing products that our lives depend on. The little machines i build at home are for personal use and for fun and learning. They will never be used by anyone other than myself and they certainly won't ever machine critical components. So steppers are the "perfect" choice in this case ;-)


Graham Stabler
11-30-2010, 11:17 AM
We can only hope engine manufacturers measure their parts before installation :)


11-30-2010, 01:36 PM
Servos have an encoder which is used to provide velocity and positional feedback to the drive system..... For steppers, you have zero feedback - it is completely blind.....

thanks for the explanation.
I've heard of steppers using encoder feedback so they don't run blind. Any idea how a stepper+encoder system like that might compare with a servo+encoder? In the case of the stepper+encoder, does the encoder buy you anything besides warning you when the stepper might have skipped some steps?

thanks again,

11-30-2010, 02:55 PM
There is an icon on my desktop where I place certain posts that I consider exceptional. This is one of those posts. Thank you.

12-01-2010, 11:18 AM
@ Graham...

It has been a number of years since I have done a project for the aircraft industry so I can't say what the current situation is in that regard. However, in nearly every other industry, this is how inspection is performed....

When a company buys a machine to make parts, it starts out with a qualifying run-off. The sample size can be anywhere from a hundred parts to a couple thousand parts. The purpose of the run-off is to determine if the machining process (and machine) are statistically capable of producing consistant parts that mathematically assure a high percentage of the parts are perfect. Over the years, the name for this has changed ( capability study, six sigma, 8 sigma, cpk run-off, capability run-off, etc. etc.) Most of the "common" names for this are localized to the customer but basically it is all the same thing. Anyway, basically what happens is you run the sample quantity, you inspect every parts, record every size, process the data to see if it statistally is acceptable. Two elements are important: consistancy and amount of deviation (size change). If you have a tolerance of .001" on the engineering print, your goal is to use about 1/2 of that during the process (very general rule).

After this qualifying run-off is completed, the machine is put into production. From that point on, not every part is 100% inspected, only perhaps 1 in 5 or 1 in 10 because statistcally the process is "Capable" of producing perfect parts. Therefore in most industries every part is NOT inspected, generally it is the minority.


When a stepper has an encoder it does close the positional and velocity loop, but only if the driver or controller software has the logic for it. Many servo drives monitor that loop and report back to the controller software. Not too many stepper drives (I don't know of any off hand) that allow for encoder feedback. So to close the loop, the encoder is fed back to the control software where the loop is closed. As to how well that data is processed, is up to the control software.

The control software may only check for a "disconect" meaning that there is a difference between where the position should be and where the encoder says it is at. It might also try to correct the problem by adding a few more steps to the pulse stream. But I really don't know what pre-existing drives or controllers do specifically - closed loop stepper systems don't appear to be as "standard" as servo drive systems.


Graham Stabler
12-01-2010, 12:01 PM
Mariss at geckodrive was working on an "unstallable" stepper, of course that is not really possible but what he did was use the encoder feedback to reduce the feedrate to reduce the error and as we know the stepper torque increases at lower speed. Just like a servo there will come a point when it faults but it was a neat cheap solution to boost performance a little.


12-02-2010, 12:19 AM

That was a neat idea but certainly not for CNC applications. The "adaptive" drive concept would adapt the feedrate to compensate for the additional resistive forces (heavier cutting, heavy load, mechanical binding, etc). However this would be performed at the drive level, not the CNC level. So, lets walk through why this is just as bad as missed steps...

You command a 3 axes motion, all three axes have to start and stop at the exact same time to create a straight vector (line) between the start and end points. If any one of the axes is not moving in synch with the others, your vector is not straight. Because his idea was to put this "Solution" in the drive, it creates a gapping hole in the CNC system. One drive could slow down to accomodate the problem, while the two other drives continue at the commanded velocity. How is this any different than missed steps? In a CNC application, the part would already be scrapped.

Now, is this a neat idea or concept for conventional automation type projects? In many cases yes. In general motion control, you are not concerned that you have a perfect vector between two or more axes. Therefore, you can get away with one axis moving slower.

But there is the next level of the problem, in many automation projects, timing is critical to the process' efficiency. If a drive allows the process to slow, the net output of that process could become a variable or even just simply slow down. If in the "whole system" you need a throughput of 1 piece every 10 seconds, one of the elements slowing down causes problems for the rest of the system with the final result being slowed production.

A perfect example of this is a gantry loader feeding a CNC machine. If the gantry loader slows down to the point where the CNC is waiting for the loader, cycle time increases, productivity and profits drop.

The concept of what Gecko drive was working on is an old technology for CNC systems. I don't know of the exact earliest date it was first utilized but it was in the 70's. It is also used extensively on EDM machines and it is called "adaptive control". But because this is performed at the CNC (control) level of the system, all axes would slow so the vector remains true during the motion.


Graham Stabler
12-02-2010, 11:09 AM
It was to be performed by the motion controller (g-100/r-rex) otherwise it would be pointless as you say. If a motor starts to miss then its speed is reduced along with the other drives to maintain the correct motion profile.

Otherwise feedback from steppers only warns you when things go wrong, steppers always apply full drive so if you are losing steps the only thing you can do is stop or slow down to increase torque and try to reduce the error. This is a basic feedback loop which technically makes them a servo of sorts (servo being a general term for an actuator and feedback system). It has nothing to do with adaptive control where the control law itself is adapted.


p.s. Here is the prop driving a stepper using the counters:
Still need to sit down and write the explanation.

12-04-2010, 07:40 AM
Hi Guys,
I have been a bit busy this week and havn't really achieved much - so I can't really report any progress at this stage.
As I mentioned at some other time, I have a modified EMC gcode compiler running on a windows machine, which produced coordinates based on a 1mSec time base i.e. move to this position in this period. I have been thinking that possibly I should modify it a little more so that it is actually outputting a number of steps to execute per 1mSec period.. What are peoples thoughts on that??? Good idea or not??? This way I can take more load off the prop, because it doesn't need to even bother with how many steps to do per mm, it just recieves do this many steps in this period.


12-04-2010, 10:38 AM
@ Graham,

Ah yes, the G100/GRex thing that failed on so many levels. Okay, so they were planning on adding the logic to that to create the "unstallable stepper". That would make more sense than what was originally talked about "The unstallable stepper [drive]". I guess I just gave up reading about it early on when they were talking about the unstallable stepper and everyone was thinking how great it would be. I suspect that it still never came to life though because the G100 had so many problems etc.

@ Andrew,

One way or the other you are working with a series of steps. Either you take the coordinate and compare it to a position then substract to the number of steps in the Prop or you do it on the PC side. I suspect that will be the least of your challenges and certainly one of the easiest to change should you need to.

The one thing that concerns me with that method of time slices is balancing the spacing between steps. You have to make sure that the spacing between steps (velocity control) carries over from one time slice to the next. I have not yet had time to really focus on this but the few brief moments I have had to think about it, I keep stalling on the timming issues. It very welll could be very simple but I just have not been comfortable enough with the concept yet.


12-04-2010, 10:42 AM
@ Graham,

I just watched you video and going by the sound alone I would say that you have a very good pulse stream using the counters. It also sounds like there is accel / decel being applied. Yup, you got to document and post the information on this.


Graham Stabler
12-05-2010, 12:18 AM
Andrew, if you have a sytem that works on a given number of steps in a given time then you have something that is basically a velocity based system becuas it is a distance in a given time. This means you can also think in terms of step frequency in a given time. This is what my program is based on, i will try to write something tomorrow about how it works.


I don't know what happened to the g-rex, i read abiut it with interest and copied some of the ideas for my work but had not looked at the page for at least 2 years, i expected a perfected product but instead see it has been canned. Shame because parallel ports are getting rarer.

And yes the motion has accel and decel, I want to program some multiaxis soon and then look at how to tie vectors together, I just finished up a little mill project that will make a good test bed.