I am currently working on controlling a SCARA robot and I have found the stepper motors to be skipping steps.
Using the code below I am trying to find the software prevention as the stepper motors and drivers are brand new.
#include <AccelStepper.h>
#include <MultiStepper.h>
AccelStepper Z_axis(1, 6, 7); // pin 6 = step, pin 7 = direction
MultiStepper steppers;
void setup()
{
// put your setup code here, to run once:
Serial.begin(115200);
steppers.addStepper(Z_axis);
Z_axis.setMaxSpeed(2000); //homing speed
long positions[1];
}
void loop() {
positions[0] = 0;
steppers.moveTo(positions);
steppers.runSpeedToPosition();
delay (100);
positions[0] = 1600;
steppers.moveTo(positions);
steppers.runSpeedToPosition();
delay (1000);
}
With this code (and using the multistepper library) I have found that on each directional change my stepper will skip 1 step.
My theory is that the skipped step is caused by the motor not stopping at the right time. However, I don't seem to be able to find what might be wrong in my code.
Therefore I would like to ask if any of you see a mistake I have made.
This is impossible, That code cannot even be compiled. It contains several mistakes.
positions is defined in the wrong place and it is used in the wrong way ( why do you define it as an array? In moveTo(positions) you use it like a simple variable.
And I think your stepper isn't able to run with 2000 steps/sec without acceleration/decelerating.
This is the second measurement. This shows that after 1 CW and CCW movement 1 step is missed (atan(0,47/200) = ~0,13 degrees, so allowing for measurement mistakes it comes out to roughly 1 missed step as 1/16 is used which is 0,1125 degrees).
That might be true, however even at 200 steps/sec at 1/16 it still skips 1 step. In terms of the acceleration being used by the multistepper that is also correct I forgot to clean up the code for the multistepper library sorry.
In terms of the code not compiling I have no clue for me it seems to work, just to be sure I cleaned up the code and reverified it.
This is based on the example shown in the multistepper class reference. I agree it looks a bit strange, the usage of it will become more clear once you see the full SCARA robot code which uses several motors which need to be controlled at once. However, since I experienced skipped steps, I thought I would troubleshoot the same code, modified for 1 motor, in order to find the problem
#include <AccelStepper.h>
#include <MultiStepper.h>
AccelStepper Z_axis(1, 6, 7); // pin 6 = step, pin 7 = direction
MultiStepper steppers;
void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
steppers.addStepper(Z_axis);
Z_axis.setMaxSpeed(200);
}
void loop()
{
long positions[1];
positions[0] = 0;
steppers.moveTo(positions);
steppers.runSpeedToPosition();
delay (100);
positions[0] = 1600;
steppers.moveTo(positions);
steppers.runSpeedToPosition();
delay (1000);
}
Ok, I see. The MultiStepper methods differ from the Accelstepper mothods even if they have the same name. And if you will use multiple steppers in the future, it may make sense to test with multistepper.
But nevertheless I would try with Accelstepper and acceleration to see if the missing acceleration is cause of the issue.
You could also try setting the microstepping on the driver to a higher value. This might improve the accuracy of your motor and reduce the risk of missed steps.
No, it increases resolution but does not improve accuracy. The position of microsteps is less accurate than the full step positions. The accuracy of the step positions in the datasheet refers only to full step positions.
And as far as I understand @cptblueberry1 he already uses 1/16 microsteps. Maybe this is the reason for his measurement.
@cptblueberry1 : does the error accumulate with many CW/CCW movements? And I don't see a stable mechanical connection between the stepper and your measuring equipment.
Basically, it's time to debug. The code looks ok, unless acceleration is still an issue.
Try eliminating microstepping altogether perhaps as a test. Make sure your stepper and gauge are clamped down.
Maybe step away ten steps and come back ten. Do it over & over to look for accumulating errors.
Steppers and mechanicals can be tricky to figure out - too many variables - change one thing at a time to get more clues. I'd also abandon the library for now as part of that experimentation.
I've spent more hours than I care to remember working with a friend to debug a problematic stepper setup. IIRC, we found three or four things that were causing our issues - quite a headache.
As you say that it always loses 1 step I wonder if there is an issue with the polarity of the direction signal so it changes at the wrong time (after) the step pulse edge? So the first step would be in the wrong direction perhaps?
Sorry for the late reply
Yes the error does accumulate every time a switch between CW and CCW movements is made. For this reason I believe that @jhaine 's hypothess might be correct. I will test this later this week . In terms of the measuring setup I agree it is not the best. However, the small mistakes caused by it can be rounded off during calculation showing clear 1 missed step measurements.
I will test this hypothesis and update you all on the findings:
Just as a reference point... I have built a pendulum clock which is maintained by a gravity arm that gives a small impulse to the pendulum once a minute. The arm is lifted by a cam rotated one direction then the other by a small stepper motor. I use a DRV8834 driver on 9V. The step pulse sequence makes no attempt at gradual acceleration and deceleration, it just starts and stops. Initially I had trouble with missed steps and stalling when the rotation was too fast so I increased both the step rate and the microstep ratio and the problem went away and the motor got quieter too. The motor makes 28800 moves every day and has done for 4 years and never missed a step.
I agree it is not the best. However, the small mistakes caused by it can be rounded off during calculation showing clear 1 missed step measurements.