The possible reasons that cause the different motor strokes of two directions

dc motorh-bridgemotorstepper motor

The question may be a little too specific since it refers to some special choice of the motor parts that may not be used for everyone, yet I would like to learn about the general debug methods if similar problems occur.

I used a motor driver QJ-215 or CW-215 to control the moving of a linear stage PSL-85. My Labview program sends out the trigger pulses to the motor driver in order to control the direction and step size of linear stage. The pulse sequences for both directions are the same, so the linear stage is supposed to achieve a raster scanning with the moving distance same at both directions (+x and -x). The whole system works well.

Now I have an exactly same motor control circuit as the worked one. However, there is a problem with the new motor control part: the distance that the stage moves along +x axis seems more than the one it moves back (-x axis). As a result, the linear stages moves far away the original starting points as the scanning proceeds.

I can exclude the software glitch because: (1) it all worked well on my previous motor control circuits; (2) the pulse of direction is always provided prior to the pulses of moving steps in both direction, so there may not be pulse missing.

I also excluded the possibility of QJ-215 damage (H-bridge circuits broken, transistor not enough gain, etc.) since I have already changed another QJ-215 but same problem existed.

So there may be something wrong in the circuit connections onto the motor driver QJ-215. As you can see, the motor driver is not complicated designed with only a magnetic coil (A+,A-,B+,B-), and the H-bridge circuits with a bi-switch (DIR) and a step pulse receiver (CP)). I would like to know what kinds of errors in the circuits connections may cause such a unequal moving distance along +x and -x direction of the linear stage?

Best Answer

How is motion feedback produced? The first time I tried to program a robot with motion feedback (decades ago), I failed to consider that motors could coast a little bit when they were powered off, and so attempting to move the motor e.g. 23 pulses would sometimes cause it to move 23 and sometimes 24. That could cause the next move to be processed incorrectly. To solve such problems, one should (1) slow down the motor as it approaches its destination, and dynamically brake it when it reaches its destination, to avoid or minimize overshoot, and (2) use a constantly-modified quadrature encoder to determine when overshoot occurs, and adjust the next move request based upon the overshoot (each count of overshoot should shorten the next move by a count if it's in the same direction, or increase it if it's in the opposite direction).

Related Topic