Is there any reason for missed steps only at low speed

Is there any likelihood that a stepper motor would miss steps at low step rates when it runs without missing steps at high rates and during acceleration and deceleration? I am hoping that somebody knows of a logical reason why this should happen. Further details below.

The system is intended to swap the heads of a 3D printer and the main part is a NEMA11 stepper motor driving a 20:1 worm gearbox. Both ends of travel are limited by microswitches. The drive for the system is provided by a Pololu type A4988 stepper driver board, supplied 24V and current limited to 0.3A and used in a full step mode. The drive pulse and direction signals are provided by a PIC16F1824 and the program provides an initial function of determining the number of pulses from one limit switch to the other and then using this distance in operational moves to check for any loss of calibration. Measuring the distance is done by jigging out a short distance at a low speed (16 pulses at 80pps) and returning at the same speed until the microswitch is triggered - this establishes a start point. The motor is then accelerated over 265 pulses from the same low speed to a little over 10 times as fast, driven forward for about 1460 pulses and decelerated back to the low speed over 256 pulses. Following this the motor is driven forward at the low speed until the other microswitch is triggered. A second run returns the motor to its original position and the number of pulses from switch to switch in each direction is counted.

This is where it gets wierd:

A run from the clockwise position to the anticlockwise position and back to the clockwise position will count the same number of pulses each way plus or minus 1 pulse.
A run from the anticlockwise position to the clockwise position and back to the anticlockwise position again will again count the same number of pulses each way.
BUT the numbers starting from anticlockwise will not be the same as clockwise - typically from 30 to 40 counts different.

Although I have ordered an encoder to see if I can find the missing steps but it will be a week or so before it comes all I have at the moment is the following: during acceleration, fast movement and deceleration the sound is clean but during the final phase at low speed the sound is quite rough.

The program has been re-written several times and the move command is fed only the direction to go and the microswitch to look for.

So if anybody has an idea why this could be it will save an inofensive brick wall from being further pummeled by my head.

Mike

How can you be sure your microswitches behave the same way when actuated fast or slow ?

To ascertain it is the stepper/driver, do fast identical forward/ backward mvt, slow forward/ backward, a mix ..... Mark the shaft, the moving part, measure with a caliper whatever ...to see if you come back at the same spot.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Hi MKSA,

I have done a huge range of speeds and protocols and think it unlikely to be the microswitch. At the moment I am trying to set up an encoder to compare exactly what is happening at the stepper compared to what I think I told it to do.

For the moment the problem is solved by not being too fussy, I have replaced the attempt to get a baseline by simply detecting the microswitches: I ramp up the stepper to full speed and run it until it meets the microswitch - then back off a bit and move slowly until the microswitch is contacted.

I have not given up trying to find out what is happening with the original method - I tend to get annoyed when something that is impossible happens anyway and I will worry at it until it yields. The diagrams below show what I am getting - the axes are speed against time. The jiggle at the beginning of each run is to get a precise first microswitch position in case it moved. The problem is that the distance from A to B in the first diagram is the same as the distance from B to A and is repeatable, about 1990 pulses . In the second diagram B to A is the same as the return A to B, both about 2012 pulses.




The apparent impossibility is that the second half of the first diagram is exactly the same trip as the first half of the second diagram yet the count is different. My present theory is that MplabX has some bugs that I don't know about - or maybe my brain has been leaking away.

Maybe it is time to start believing in the supernatural.

Mike

Edited 3 time(s). Last edit at 12/13/2018 02:43PM by leadinglights.

22 pulses difference doesn't sound like a binary error ( 8-16-32 pulses would be a hint ), but nevertheless did you try to store the stepcounts in an array instead of using the same register back and forth?

BTW: Is the microswitch debounced in hardware or software manners?

Edited 2 time(s). Last edit at 12/15/2018 03:47AM by o_lampe.

Quote
o_lampe
22 pulses difference doesn't sound like a binary error ( 8-16-32 pulses would be a hint ), but nevertheless did you try to store the stepcounts in an array instead of using the same register back and forth?

BTW: Is the microswitch debounced in hardware or software manners?

I think I have found it by looking at what is happening on an encoder that I connected to look at the stepper motor.

In each of the two round trips there are several changes of direction, most of which are from a standstill to a low(ish) speed. The speed at which the stepper could pull in was determined by trial and error and the figure used is 2/5 of the reliable pull in speed. The apparent cause of the error is that there is one transition in each round trip where the speed changes from 66.7pps in one direction to 66.7pps in the other direction - a change of 133.3pps. This seems to be reliable if going from clockwise to counterclockwise but misses steps going from counterclockwise to clockwise. Only the end of the "jiggle" is effected as all other transitions have a short delay between stop in one direction and start in the other. Mug-shot of the accused below.



This does not seem to be the whole of the answer as it doesn't account for the non-jiggle halves being equal, but it is possible to see that the direction transition is poor one way and good the other.

On your other point, I use no debounce at all - devilishly avant-garde I know but the only point where this may be a problem is the forward part of the jiggle and the reverse to MS detect which has a long delay due to the number of pulses in the jiggle - a sort of debounce of the serendipidous kind.