5

This may be a better question for the Physics StackExchange so tell me if I should move the question.

I have a pretty simple script that I'm using to control the RPM of my stepper motor:

void loop(){ 
  digitalWrite(PIN, HIGH);
  delayMicroseconds(wait);
  digitalWrite(PIN, LOW);
}

as you can see it's just producing a pretty standard pulse, I have my Arduino connected to a driver that manages the motor. The wait variable comes from a second order equation I derived from measuring the RPM with a Tachometer and tweaking the value.

// From data RPM = 31729/x + 17.327 thus x = 31729/(RPM-17.527)
wait = M/(RPM-C);

It works pretty well, I get readings consistently within only 1 - 2 rotations off. But the slope and intercept seem completely arbitrary to me. Is there a chance it has to do with the clock speed of the Arduino? I'm using an Uno and from playing around with the numbers I can't seem to find a relationship. From what I can tell, the driver looks hardwired so I don't think it has much to do with the equation.

Any idea what these values, the slope/intercept mean?

Equation: RPM=31729/wait + 17.327 M:31729 and C:17.327

Improve this question
2
  • 1
    I wonder if this generates a proper pulse. It needs a delay after digitalWrite(PIN, LOW);
    – rmi
    Apr 30, 2014 at 4:25
  • There's definitely a clock dependent granularity and additional delay among other potential problems. For steady rotation, consider using a hardware timer to drive a pin, or failing that trigger an interrupt so that at least the overall rate remains constant. There should be a fixed factor of step rate as long as the system is operating properly, but there will be both a rate and am acceleration at which it starts skipping steps, especially under load or resonance.
    – Chris Stratton
    May 2, 2014 at 9:42

2 Answers 2

Reset to default
2

The real answer to this question requires understanding exactly what hardware you have. The formula, assuming one step per pulse, is that the delay should be:

wait = (MicroSecondsPerMinute)(1/RPM)(1/PulsesPerRevolution) - overhead

where overhead is the extra time it takes to run digitalWrite twice and loop. It is small, but if it were zero your code would not work because the amount of time your signal is LOW would be zero as well.

Your numbers suggest Pulses Per Revolution is around 1891. This will be the product of how many steps per revolution the motor is wired for and how many bits of microstepping the driver is doing. A 225 step motor with 3 bit microstepping (8 fractional steps per "true" step) would have PPR of 1800 for example. Your number does not precisely match any common setups, but is exactly in the range expected, with 1600 and 2000 being normal for small steppers.

Because of the "overhead" term, RPM as a function of wait should not be linear. Your constant value should be a function of RPM; in fact, when RPM gets much larger than the number of Microseconds per minute it should converge to being equal to RPM. In this case your RPM is so low that approximating it to 17 is probably valid and all error too small to notice. It could be causing some of the oddness of your PPR value though.

Improve this answer
0

one pulse equals one step of stepper and rpm is how many rotation stepper makes in one minute. Try to understand the stepper.h library and Accelstepper library

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.