We have a stepper motor and microstep stepper motor controller. The microstep controller provides 128 microsteps. We need as many as possible.
We have a problem. When we study the movement of the motor closely we can see that the velocity seems to change momentarily on the 128th microstep i.e. at the step change. We believe that this is not an uncommon problem. Can you explain what the problem is and why it occurs?
The way we are measuring the problem is we have a mirror on the motor and a laser pointer reflecting off the mirror onto a target. As the mirror rotates we are imaging the target with an ultrafast camera (1000’s of frame per second). We then measure the position of the laser point on the target in every image and plot it. This clearly shows a variation every 128th microstep. We assume this means it is happening on every step change.
The microstep controller that has been used (by our contractor who designed the system) is a cheap one. Can you provide a microstep controller with at least 128 microsteps (more is better) that does not have this problem.
The motor is a 14HS13-0804S-PG5
The motor is already mechanically designed in and changing the motor model at this point in time will be a significant problem unless the replacement is a perfect match.
Is the shaft loaded against the direction of rotation? If not, what you are seeing might be backlash in the gearbox at the end of the full step, rather than any problem with the controller.
It is unlikely that anyone would have experience with this precise problem, but if you indicate the controller you are currently using the specs could be compared to alternatives that are available to see if there are any features that might be relevant to the problem.
While I’m not sure how it would compare, if you’re trying to avoid the backlash of your gearbox, a belt drive could be used instead. For example, the Voron M4 extruder uses a 5:1 reduction, using a 16T and 80T GT2 timing pulley.
Perhaps someone can comment on the comparison between belts and boxes, but my experience with belt reductions has been good so far,.
-James
I’m just guessing here, but your issue could be caused by a problem in your code.
I have seen something similar once in the Arduino specific analogWrite() function. There is a distinct non-linearity by design between analogWrite(0) and analogWrite(1) as the output changes from fully off to a square wave - I came across this issue designing a PWM → Analogue filter at uni. Here’s my summary from the report:
It is also noteworthy that there is a large step in duty cycle between 0 and 1 when using the Arduino analogWrite(). This is due to both some low level details and decisions made by the Arduino developers in attempt to make the PWM output as intuitive as possible.
At a low level, a PWM frequency request of 0 should be 1/256 duty cycle[56], and a request of 1 a duty cycle of 2/256. However, a request for 0 to ‘analogWrite()’ results in 0 duty cycle. A request for a duty cycle of 1 to ‘analogWrite()’ still results in a duty cycle of 2/256, and a request for 2 gives 3/256, and so on for all remaining values. This results in distinct non-linearity at very low PWM duty cycles.
There’s also a secondary transient effect that occurs with the Arduino analogWrite() function, which is summarised well here, and is another issue that could be causing what you’re seeing.
