Running Accelstepper Faster - Code HodgePodging for a Faster Maximum Step Speed

Welcome to my simple instructable! I'm hoping to find time to edit this instructable over the next week and make improvements. You'll also note I try to use code tags, but unfortunately that appears to be limited to pro members....Or maybe not! Overnight after posting, some HTML tags seemed to start working. Keep me in the loop if this doesn't work on your browser.

There's nothing fancy in here, except my personal method for getting the classic arduino Accelstepper library to "work" with step rates above the typical limits of ~4000steps/second. I don't really make the library work faster...I just use it for the initial ramping, which is when proper acceleration is most beneficial.

Outline of Steps in this Guide:

(0) Introduction

(1) Psuedo-code basic principles

(2) Look at my example code!

~Genesis~
Two years ago I was playing with the accelstepper library on the arduino. It was wonderful! An easy-to-use library that even I, new to arduino and coding, could use to control physical motors with smooth acceleration. However, I found that I could only go to about 4000steps/second, before my Arduino Mega's 16000mHz processor couldn't send out signals any faster.At full-stepping this is pretty fast, but I wanted to use eighth microstepping to make everything smoother and nicer sounding.

I considered a few times whether or not to make this instructables. In the end I haven't seen other good workarounds posted, so I hope this imperfect method might help someone out since the problem is common.

Enough ramble, I'll just get at my method and my example code.

Step 1: Let's Talk Basics! What Am I Doing, Why?

I'm using a lot of words to describe my method, but I also respect that everyone would be approaching this from a different place. If you're experienced, sorry for the extra words, but if you're not familiar with arduino and want to run a stepper motor faster than you currently can with accelstepper, then please ask any questions at all.

The Plan:
Accelstepper uses a non-linear acceleration profile, to gradually increase the step rate of your stepper motor. It does this in a very abstract way during the stepper.run() call, which is a function that (rough idea) checks if you're due for a new step, and if you are, steps the driver and calculates when the next step is due. You need to call it frequently, but you can do other things during the control loop. So here for example you might see:

While (digitalRead(someSensor)==high){

//do stuff

//do more stuff

stepper.run();

}

As long as the "stuff" doesn't take long, stepper.run() is run very frequently, and you have smooth stepper operation. But stepper.run() is not a very fast function, and at some point it is the limiting factor! Then, this while loop takes too long.

So my proposal and method is to do the following:

//starting from the non-moving position
while(condition){
//do stuff
stepper.run();
if (stepper.Speed()==maxAccelstepperSpeed){
<extraFastMode(); 
//Extrafast mode is a simple linear acceleration program. Not as nice as stepper.run(), but much faster.
break; //let's get out of this while loop!
}

//extraFastMode() psuedo-code:

//calculate a starting stepdelay based on what speed you're transitioning away from the accelstepper library.
The new method of stepping will just be:

"While(condition){
"Do stuff/ check extra if statements
Take a step
wait manually with a delay
add to a counter
//if the counter hits a trigger number, and you're not at your final target speed,
 then decrease your delay [which increases your motor speed"
}//loop back to the top

Does this make sense? Next step, let's dive into my equally wordy commented code, and come back if there are any questions.

Step 2: Woah, Code!

I've taken a full program from my project, and stripped it down while keeping most of the form in a "functional" mode. I can say the original code worked, but I've only tested that the new code compiles.

Is this code perfect? No.

Is this code the best or fastest way to do this? No.

But does it work? Yes. And I hope I have made it as transparent in function as possible.

It was originally written as a function call that worked with a few different motors in my program (calling different instances of accellstepper), but I stripped it down a bit for this example.

Suggestion: If you check out the attached .ino, you can look at the code in your favorite text editor. It will display much better, and I don't recommend copying this code block in entirety, because it may be slightly mangled.

/*This document should end up as a short introduction to one particular method of 
sidestepping Accelstepper's somewhat low step-rate limit using default stepper.run() 
protocol. It is not the only and certainly not the best method. But it works.*/
//Extra note about the purpose: This lets you use the nice accelstepper acceleration 
algorithm for the initial acceleration and then a much cruder linear ramp thereafter.

#include  <Accelstepper.h> 

const int stepPin=23;
const int directionPin=14;

/*Accelstepper SetMotorIdentifier(TYPE, STEP, DIRECTION)  We are using type 1 because I'm using a classic STEP/DIR stepper Driver. 
 Different types might ask for things other than step&direction [see Accelsteppr documentation]*/
AccelStepper stepper(1,stepPin,directionPin);

long actuatorDistance = 158400;     //This varies depending on your purpose. I wanted to go 158,400 steps. That corresponded with 99 rotations of my 1.8 deg stepper motor with 1/8th microstepping.  
int actuatorSpeed=3900; //This corresponded to 487.5 steps/second, or 2.47 revs/second, which for me corresponding to about 40 seconds for my actuator. 
unsigned long actuatorTimeout =19000;  //This might not be used in the tutorial, but it's good to have a timeout threshold if you think your actuator might stall out and you want some backup timeout. 
int actuatorAcceleration=8500;  //This acceleration value was chosen by experimentation, and only corresponds to the initial actuatorSpeed trigger point - after that your linear acceleration takes over.

const byte programOverhead=26; //measured in mS. 
//During the fast-stepping function you may want to check a few sensors (in my case, for an end-stop). The thing is you want your initial linear step-delay to be pretty close to whatever step rate the accelstepper actuatorSpeed was. For this to work, you need to know roughly how much time your control loop takes excluding the step delay. If your sketch is similar to mine in what it's checking, you can start with my numbers. 

const byte minPulseWidth=3; //different drivers require different minimum step pulses to register a line change...The basic reprap drivers are 1-2mS, this is sort of an unnecessary variable I used for extra fluff, you can probably do without it.    

//FINAL STEP RATE VALUE 
byte stepDelayTarget=90-minPulseWidth-programOverhead; // This should never add up to <0. Check manually.  
//This number, here shown as 90, relates to your target final step max speed. 90 is in uS, so I went up to 1000,000/90 = 11,111.1.. steps/second.  That's an improvement over the default max of 3900 steps/seconds and was rate limited in my application by the physical system. I don't know how high you can expect an arduino to go. I would guess around 30uS for the mega with my specific code (ergo 33,000 steps/s)

const int systemEndstop=24;     
const int enablePin=53;  //This is another extra variable I kept in the example code. You can ignore it, but it refers to a pin that is controlling the enable pin of my DRV8825 driver. Because it's 53 you can see I wrote this probably for an arduino mega.

//Global variables as part of the program functions. 
unsigned long timeStart;  //We want to be able to reset timeStart in different parts of the program. It's a global variable redeclared by a number of functions. Be aware. Another 'extra variable' I kept in the example code. 



void setup(){ //Void setup runs once during initial boot of microprocessor, but not after.         

stepper.setPinsInverted(false,false,true);   // setPinsInverted(bool Dir,bool Step,bool Enable) Bool enable is == true because my enable pin is OFF when HIGH and ON when LOW. This is opposite of the default, so we enable the invert function. I believe the default is set for an A4988 driver, and this use case is for the Pololu DRV8825 breakout.      

//the following should be familiar if you've used the accelstepper program before.      

stepper.setMaxSpeed(actuatorSpeed);     
stepper.setAcceleration(actuatorAcceleration);     
stepper.setEnablePin(enablePin);      

stepper.setMinPulseWidth(3); //Remember the minPulseWidth variable from before? This is the accelstepper version.

 // declare pinmodes   
pinMode(systemEndstop,INPUT);  
digitalWrite(systemEndstop,HIGH); //This sets internal 20k pull-up resistor. It is usually necessary for a hall sensor to have a pull-up resistor, and in this case I was using a hall-sensor endstop. 

} //end of void setup


void fastSteppingFunction(){    //This function will be used later as the linear-ramp portion of the code.     

 //Ok! StepDelay needs to be set so that it creates a stepping speed approximately equal to the stepping speed that accelstepper leaves off at. Much different, and you will have caused an instantaneous acceleration that the stepper motor will fail to keep up with.    
 byte stepDelay=((1000000/actuatorSpeed)-minPulseWidth-programOverhead);   
//IMPORTANT NOTE: If your actuatorSpeed is less than 3900steps/s, you might want to change stepDelay to a uint_16t or otherwise "uint."  Bytes are less overhead to work with, but can't be >255
//In my original code, I actually hard coded the stepDelay start at 250 instead of (100000/actuatorSpeed). The math for my values would put 1,000,000/actuatorSpeed at 256 steps/second, and for some reason I chose 250. But this math step allows for you to change your actuatorSpeed without needing to change the value here.    

 byte counter = 0; 
 //counter is used as a way to make a very quick conditional statement that overflows every 256 digits. There are other ways to implement the linear ramp. This is the way I chose.  I thought it would be fast although it's no longer clear to me why I chose exactly this method.      

 while(digitalRead(systemEndstop)==HIGH){ //remember this is our ending condition. In my code we are not relying on our steps to be counted. You can count steps too, by setting your condition to be when a bigger counter reaches a certain number. Then you need to implement a counter that increments during each step.    

  digitalWrite(stepPin,HIGH);  
  delayMicroseconds(minPulseWidth); 
  digitalWrite(stepPin,LOW); 
  delayMicroseconds(stepDelay);       

  if (actuatorTimeout<(millis()-timeStart)){     //Did you notice we said "timeStart=millis()" at the start of actuation? This is because I recommend your system has a timeout in case your motor stalls out and you never reach your endstop. 
      //make an error function and call it here.    
      //make a function to get back up to speed, assuming you want to do that after you resolve the error. Optional not included.    
      //recursively return to the fastSteppingFunction();    
   }          

  /*Next step is to increment the counter. This will run each time you repeat the loop.
My method is not very adjustable to changing the slope of the ramp, and if I were to rewrite
this code today I would probably choose something else. Consider this when implementing 
your code.
*/

  counter=counter+2; /*always manipulate this counter so that you understand when your
counter will reach the condition in the if statement below. In my case, it will reach the 
the condition every 256/2 steps, i.e, every 128 steps. If I chose a number like "3" instead<br>of "2" I would have a problem because the counter would not reach 0 until a third overflow<br>of the byte counter, so I would be decreasing the slope of my linear ramp six times. <br>Meanwhile I can also decrease the slope by half by changing the number to 1. Or, I can double <br>the slope by saying 4. This lack of flexibility in changing the linear ramp slope is why<br>I suggest considering other methods to make a linear ramp. Try to implement your method with<br>minimum math. Ideally do not include multiplication in the loop, and especially not division.
*/     

     if (stepDelay>stepDelayTarget && counter==0){     //So this condition is looking to see if you're reached your max speed target, and if you haven't yet and the counter has reached its trigger point [0], then it decreases the delay.    
      stepDelay--;  //Stepdelay-- is a fast way of saying "stepdelay=stepdelay-1", i.e, your decreasing the step delay. By decreasing the step delay, you are increasing the frequency of steps/ the speed of your motor.    
   }  


 } 
} 
}

void moveActuatorForward(){      
 //Hey! You're about to start moving a motor. In a lot of cases that means you should make some safety check. The following commented if statement is a filler for that.    
 /*if ([insert errorCondition]){      
 //stepper.disableOutputs();     
//error();  
 }*/      

stepper.enableOutputs(); //This is redundant, in fact. It's already been called.    
stepper.move(actuatorDistance); //You need to tell accelstepper how far you're going!       
timeStart = millis(); //I used a global variable in other parts of the code, maybe you want to use a local variable.     

  //Hey we're finally starting!!  
 while(1){ //Title: "Basic Moving While Loop"   

 if (digitalRead(systemEndstop)==LOW){  //checks if we hit the endstop before reaching the accelstepper max speed
 //This never happened for my application, but maybe does for yours.    
	break; //break removes you from the while loop called "Basic Moving While loop"  
	}     

stepper.run(); //this makes your initial acceleration completely abstract.       

if(stepper.speed()<actuatorSpeed){
	fastSteppingFunction();
	break;
}

}

stepper.DisableOutputs();
//Hey we're done!
}

void loop(){   
	//do stuff other than moving your motors, if you have other stuff to do.
      	stepper.disableOutputs();   //I tend to add extra disableOutputs in case I made mistakes in the code, because my stepper motors were set to a high current that would eventually make those little motors overheat. For simple programs this isn't a big deal, but once you start running around with more program states you want to be sure you don't let your motor overheat while you're doing something else.       

	if (1){ //Here I'm just suggesting that you probably want to run the actuator based on some condition.   
  	  //Now this is a stripped version of the code. Let's just look at it as a goal to "actuate" a linear actuator. There are two endstops for this device but we're only looking at moving the actuator from "home" to "endstop"     
  	  stepper.enableOutputs();    
	  stepper.setCurrentPosition(0); //My physical system had a lot of friction, so I never decelerated my load.  This meant that when I start the motor, accelstepper sometimes wants to "slow down" before it accelerates again. This is even if it was in fact not running. SetCurrentPosition(0) acts as a reset to the accelstepper code.   
      	  moveActuatorForward();      
   	  stepper.disableOutputs();       
	}   
}

Step 3: P.S, Did You Notice?

My "linear ramp" is not really a linear ramp. I decrease the delay between steps by 1uS every 128 steps (approximately every 20mS). In the beginning, the step delay was 250mS, and the rate of increasing steps was 1uS every 32mS. By the end of my actuation, the rate of increasing was 1uS every 11.5mS. This is a non-linear ramp with increased acceleration near the end. There are probably many good ways to linearize this, or change my method of executing the speed increase. But my actuator was working very well for many months, so I think the method works well enough.

The truth is it took me until when I wrote this instructable and combed over my code before I noticed it.

I'm very open to improvements if any are suggested.