Main Site Documentation

Driving stepper with different step sizes



I’m currently writing a driver for a stepper controler (EasyDriver) and I’m wondering how/if I should deal with different step sizes :think:
EasyDriver has 4 “speeds” : Full, Half, Quarter and Eighth step. I take 1/8 as a base since it’s the lower step size.

Now, say I’m at position 100 and I want to go to position 120. In this case, I can do :
[ulist]20 pulses at 1/8
10 pulses at 1/4
5 pulses at 1/2
2 pulse at 1/1 + 1 pulse at 1/2[/ulist]

If I somehow forget about the complexity of such calculations, do you see any practical reason that would prevent such a way of controlling the stepper ?
I think at precision, for example, or accuracy in positionning. Both may not be as good in 1/1 vs 1/8. But long moves would last too long at 1/8, of course.
Of course, I need precision and accuracy.

Right now, I will start at a fixed speed of 1/8 so that I can progress in the driver coding but this question will arise sooner or later :hand:

What do you think ?


I think it depends on application. But i would rather have the ability in the driver to choose how I want it to be handled. Then in my application I will have presets or something like that. I hope that make sense. Happy New Year!


Hi Bec :wink:

I made a driver for steppers here :
(there is some interresting links in the description)

Different ways of driving a stepper motor has more implications :

  • various torque (couple in french) for each method
  • various precisious as well. If I remember well, some stepping method like the “half” do not have exactly the same step size for each of its step, or the same torque for each step ( )
  • not al stepping method use the same driving current (“hi torque” use twice current than the wave drive).

So it’s good to have different stepping methods available and let the driver’s user choose what he needs, function of his application !

Have fun :wink:

So all depends what you need.


I have a question this time :slight_smile:

Why would someone prefer to use a brushed motor over a stepper motor in a robotic application? Since with stepper you almost do not need encoder and you have tight control over the movement then why use brush motor?


Encoder for the stepper ?


Thanks to all for your comments.

In fact, the application is a motorized focuser (for telescopes). Depending on the aperture of the “telescope” (refractor or reflector, doesn’t matter), the required precision is not the same. A scope opened at f/15 does not need much precision, while a f/4 one will require very high precision.

But… depending on the position of the focal point, the focuser may have to do a long travel to reach this point. If I do this travel at 1/8 stepsize, it will take very long time, hence the “high speed” option with full step (for example).

@ Architect : this could be an option but there’s a small problem with such presets. You will have to use the lowest stepsize as a unit, so that precision is available, but in turn you won’t be able to go to some positions while in full-step mode, since (in this case) it will have to be a multiple of 8 (starting at the current position). e.g. : if I’m at position 100, in full-step mode I won’t be able to go to position 105. 108 will be ok, as will also be 116, but not 111.
You see the problem ?

@ Nicolas : I (also) need torque ::slight_smile: But this may not be really mandatory if I use some kind of gearbox.
But you’re right on one point : precision is less in lower stepsize modes… By design.
It’s not the first driver I’m writing for steppers (or brushed CC motors) : for example :wink:
But this time, I wanted to fully use all the features of the EasyDriver, even though it eats up a lot of IO pins.

Btw, I could also use high-step sizes to do some pre-positionning, then use 1/8 or 1/4 for precise positionning. Again, I have to be careful with “high-speed” because the load can go as high as 3-4 kg on a focuser and moving this load too fast could be risky, mainly because of the price of the “load” : big CCD camera + filterwheel + interferential filters + optical correctors ???
I will still need some “ramping”, anyway.

@ Gus : maybe cost and ease of use, at first glance. Brushed motors driven via PWM and gearbox are very easy to deal with and moves are still precise enough to reach good focus (in my case). But here, accuracy is not good enough, though.

@ Rajesh : yes, you may need encoders on steppers. Since they can miss some steps because of not enough torque (because of too much load or because of a stall), for example, your driver can believe you’re at some position while you’re not !
And believe me, in astronomy, it can happens often if you do not monitor your telescope mount correctly.


Hmmm… I’ve had another idea : instead of using 1/8 as a base, I could stay with 1/1 and use lower step sizes to do the needed ramping.

I think that this would solve at least 3 problems :
[ulist]no high speed at start (harmful for things on the focuser)
the client application wouldn’t have to deal with different step sizes
calculation of the position is then very easy : 1 step = 1 position[/ulist]

Internally, the position during the ramping won’t increment by 1 but by 1/2, 1/4 or 1/8.
The driver will “only” have to choose when to do the ramping and at which rate, depending on the destination position. I think it will be easier to implement than what I wanted to do first.

Now… time to have a drink, at least, and wait for the (happy) new year to code :slight_smile:


@ Gus. The main drawback in steppers is you “know” your position. It means you hope, that motor won’t slip a step. With DC motor you need encoder anyway.
Another situation where DC better is “active break”. When moving things with high inertia, it’s simplier to break with DC than with stepper.
And holding in position sometimes depends on application. Ever wondered why rc servos is DC not steppers?


There are a lot of misconceptions about stepper motors floating around in the wild…

A stepper motor will NEVER lose position unless overloaded, if you overload a servo it will lose position as well. The only difference is that you may have some feedback from the servo drive to let you know something went wrong. (some stepper drives offer this feedback as well) (A stepper motor will also work perfectly well as a brake, see the latest Circuit Cellar for an example of a Stepper Motor being used as a dyno.)

A stepper motor has a constant power output, that is as RPM goes up torque goes down. A servo motor (AC or DC) has a much flatter torque curve, that is its torque output stays relatively flat as RPM increases (its power output thus increases).

A stepper is conceptually easier to control as you don’t have to have a feedback mechanism. Modern stepper drivers can incorporate lost step detection (with no encoder needed), can produce a nearly AC output to the coils, and often incorporate step morphing so that the driver uses microstepping at low speeds and internally morphs into full steps at higher RPMs (giving the benefits of low RPM smoothness and all the motors power at higher RPMs.

A servo requires a feedback mechinism and is typically more expensive to implement. One type of motor is not inherently better than the other, you just hvae to match the motor to the job at hand.

When using a servo you know that the motors angular position will be withing a certain range of where you tell it to go. This range is the ‘following error’, it is usually specified by a number of encoder counts. The main idea is that a servo is never ‘exact’ it is just really close to where you tell it to go (and it constantly tries to correct its position.)

There is a similar concept with a stepper motor. It will always be very close to where you tell it to go, but may be off close to a full step either way. When microstepping you increase resolution of movement (i.e. the number of distinct positions) but not accuracy (microstep positions are not accurate.) Think of this like chopping up paper into confetti. You could do a fair job of making accurate 1cm long strips of paper, if you tried to subdived each 1cm piece into 1000 smaller pieces you would wind up with much smaller pieces of confetti but probably not very accurate pieces. Some will be longer than others.


Thanks Jeff. You gave me exactly what I needed to know


I’ve just put the first version of the driver on the code site :

If you have any question about it, do not hesitate to ask. The example code has been made for a Domino board, but I’ve used the “standard Arduino” pins, so it should compile as is on a Panda/PandaII I think.

Remember though that it’s a driver, not a complete client application. It means that there’s no really complicated methods in it, except for the Move() method. I thought this one needed more than a simple (and frustrating) pin assignement…

Even though I have a working code for the Decay modes, I didn’t put it in this version, because I have first to find out how I can ignore this pin in the Init() routine if the user doesn’t want to use it. It’s easy for normal GPIO pins since I can use Cpu.Pin.GPIO_NONE but there’s no equivalent for AnalogOut.
I think I can safely assume AnalogOut.Pin.Aout0 since there’s only one analog output on all boards, but I still have to check it out to be sure.