Stepper positioning error after reversing

Robotics
1

I am using the Big Easy Driver and a 400-step stepper motor (ROB-10846 from Sparkfun). This is a 3v 1.7 A NEMA-17 motor, and was suggested to me by Brian Schmalz. I am using it in 16-microstep mode.

The problem I am having is that whenever I reverse the direction of the stepper motor from the previous move, it seems to lose about 8-10 microsteps. Thus if I move it forward (say) 4 full steps, and then back 4 steps, it returns to a position that is 8-10 microsteps away from where it started. Unfortunately, my application requires a positioning repeatability of no more than about 3 or 4 microsteps. If I set it stepping very slowly (~1 microstep/sec), I can see that it’s the first 8-10 microsteps that are lost - I can hear the motor pulsing but it doesn’t move. Any moves in the same direction as immediately prior don’t lose these microsteps.

Changing the current limit into the stepper motor doesn’t seem to help. I have set it to about 0.8 amp, and my power supply is 12 volts rated for 2 amps.

Here is what I am doing. When I initialise the driver, I set it to what is described on the A4988 data sheet as the “home microstep position” by means of the RESET command. All my subsequent moves are multiples of 64 microsteps (4 full steps) which should again leave the driver in this home position. I provide a delay after any change of direction before beginning stepping - even a 1 second delay doesn’t help. I have tried it both with and without going to SLEEP after each move, with similar results.

I am controlling the stepping and positioning with my own Arduino software, as this gives me the best control over what is happening. I don’t need the features or the learning curve of AccelStepper.

I had the same problem with a different stepper motor (200 steps, 12v) and the original Easy Driver.

Does anybody have any thoughts as to what might be causing this problem, or any suggestions as to what I could try?

Or is it too much to ask of the BED/motor combination to get the performance I need?

Thanks,

Paul.

P.S. This may or may not be relevant, but I noticed that pulses 8, 24, 40 and 56 in each sequence of 64 microsteps move the motor twice as far as the others, and each pulse immediately following one of these doesn’t move the motor at all. These positions correspond to the zero-crossing of the current into one or other of the motor coils.

2

Are you moving a heavy load on the motor?

3

There is very little weight as such, and what seems to me to be only a small amount of friction - I can easily push the unpowered load/motor with a finger (at a radius of 6") and the ‘detents’ between motor poles are more prominent than system friction. But I don’t know if that is a heavy load or not. Also, when operating and just before issuing the reverse command, I have tried manually pushing the load in the reverse direction (not so far as to actually cause a move, but until I felt the resistance of the motor), to ease out any frictional effects and any hysteresis or slack in the coupling between motor and load - without any effect on the problem.

I do need the 0.8 amps to avoid missing steps, but doubling that to 1.6 A doesn’t make any noticeable difference to the problem.

Trying to see what’s going on is complicated by what happens when I issue a SLEEP or DISABLE command at the end of a move. A subsequent unSLEEP or ENABLE in preparation for the next move causes a slight jump in the direction of the previous move, and that causes the positioning error to be a little worse. But I still get positioning errors in the absence of SLEEP. I’m eventually going to have to resolve this SLEEP/DISABLE issue, since I need one of them - but one thing at a time.

Paul.

4

Microstepping is generally used for smooth running and to avoid resonances at certain step frequencies, not for accurate stepping.

In addition there may be indexing issues in the driver, as the microsteps are indexed from the last full step position. So, when reversing, the driver might start the indexing over from the last full step position. Check the data sheet. Microstepping does not work properly if the current limit is not set and functioning properly, and the Easydriver won’t support 1.6A / winding.

For higher step resolution use a toothed belt drive, or a gear reduction drive with antibacklash measures.

5

Thanks.

I am trying to ensure that I only stop at full-step positions, since I am using the microstepping, as you say, to give a smoother motion. That is the reason why I start off at a full step position (what Allegro describe as home microstep position) and only ever increment 64 microsteps (= 4 full steps).

Following TS Brandon’s comment (although I was initially unsure) I had another look at the load on the motor. It appears that there may be sufficient static friction to cause the mechanism to be slow to reverse. I took everything apart and addressed this with re-alignment and lubrication, and things are better now, and my initial query seems to have been resolved.

Given that resolution, there is now a different issue. The nature of my application is that motion will be very intermittent, with long pauses between moves. And as I need to drive a fairly hefty current into the motor, I need to be able to turn off the motor drive outputs when not in use, to minimise chip heating. I thought of using the BED ENABLE command for that. But, even when the driver is in the ‘home’ position (i.e. at a full step position) when I dis-ENABLE or re-ENABLE the motor outputs, I get a jump in the motor position, which varies depending on previous move history. This is presumably because these commands reduce motor current to zero in both windings, which doesn’t correspond to a valid motor position. Consequently, I am still getting positional errors if I do this.

So here’s my new question. Is there any way of using the ENABLE, SLEEP or RESET commands (or any other) in such a way that doesn’t cause the motor to move, either on application or release, as the motor is turned on or off, at full step positions? Is there an optimum starting position I can invoke during setup() ? What do users generally do when faced with this requirement?

Paul.

6

What if you use some kind of encoder (magnetic ones are advertised as very precise) to restore the previous position saved somewhere in your arduino/teensy/whatever ?