Printrbot Simple Stepper motor problems

[maximrdst]

Hello, i am in the process of building my printrbot simple wood 1405 and ran across an issue with one of the stepper motors. In the picture, the extruder motor(far right one) the green and red wires are switched. Is this an issue that could cause a problem with my printer and if so how can i fix it?

[RetireeJay]

All four of your connectors have blue and red paired on one end, and green and yellow paired on the other end. That is good.

Without going into great detail about how stepper motors work, the consequence of wiring one coil "backwards" is that the motor will rotate in the wrong direction. But since there is already a "crossover" wired into the circuit board, if the motor turns the wrong direction you can fix it by simply reversing how the plug is installed to the board. It swaps coils A and B, but it also swaps the POLARITY of the connection on one of those coils. The net result is, the motor will run the other direction. I know it sounds confusing, but trust me; I've reversed motor direction by swapping wires on the plug, and I've also reversed motor direction by reversing how the plug goes on the board. There's no chance of doing any lasting harm with these swaps.

[maximrdst]

So if i just switch the whole connector around that will fix it?

[KD6HQ]

Have another look.

The wires noted by #1 and #2 appear to be reversed compared to the order in #3 and 4.
In 3 and 4 the red wire is always on the outside. I'm not sure what effect this would have if any but it does not seem correct to me.

[RetireeJay]

Have another look.

The wires noted by #1 and #2 appear to be reversed compared to the order in #3 and 4.
In 3 and 4 the red wire is always on the outside. I'm not sure what effect this would have if any but it does not seem correct to me.

Trust me, it's fine. (KD6HQ, you have a ham license, so you should know something about circuits. )

The motors have two coils: A (red/green) and B (yellow/blue). In operation, if you were to run with no microstepping, you would send current in the "plus" direction through A, then in the "plus" direction through B, then in the "minus" direction through A, then in the "minus" direction through B in order to accomplish 4 steps in one direction (say, CW). But to go in the other direction (CCW) you would send current in the "plus" direction through A then the "minus" direction through B, then the "minus" direction through A, then the "plus" direction through B. So if you look at just coil A, the sequence is always [plus, minus, plus, minus]. If you look at coil B, the sequence is either [plus, minus, plus, minus] or it's [minus, plus, minus, plus]. See the symmetry? So what happens if one pair of wires is reversed? It just inverts the "starting point" of the sequence, which amounts to changing the direction of rotation. But laine (lwalkera) designed the board with a crossover for one of the coils, so by reversing the plug on the board, you can reverse the direction of rotation of the motor. Regardless of the color codes, if the motor runs in the direction you want it to run, then don't change anything. If it runs in the wrong direction, then reverse the plug.

If the motor were very seriously mis-wired and one of the wires from coil A was showing up in one of coil B's assigned slots (of course with a corresponding mis-wiring of coil B) then no current at all would flow, and the motor would not move at all.

In no case will there be any damage to the board or the motor.

[maximrdst]

Thanks for all the help!

I just switched the connector around and the extruder motor is spinning the right way now.

I just wanted to make sure i wouldn't ruin my stepper motor by doing this.

[biglazyb11]

Hi RJ and others, I had hoped to be able to solve this without asking for help again, but I am in need of advice.

History -- Printrbot V2 originally had a Printrboard Rev. D -- I burned this up and replaced (without realizing it) with a second hand knockoff Rev. E. This also burned up, and I purchased a refurbished Rev. D from Printrbot.

Assembling everything went fine (though I did discover that the new ubis hotends have a EPCOS thermister instead of the AD595, so there was a change needed in the firmware to #define TEMP_SENSOR_0 6 and #define TEMP_SENSOR_1 6 or else the extruder reads 485 degrees when it should be room temperature).

I have now flashed Marlin distributions of fimware Marlin_Marlin_v1, Marlin_unified_V2 and Marlin_unified_V3 on to my board one at a time to try to solve this. Each time there is the standard Y axis inversion issue, which I was able to rectify using the changes in Configuration.h:

#define INVERT_X_DIR true // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR false // for Mendel set to true, for Orca set to false
#define INVERT_Z_DIR true // for Mendel set to false, for Orca set to true
#define INVERT_E0_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E1_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E2_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false

// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR -1
#define Y_HOME_DIR 1
#define Z_HOME_DIR -1

And the Y axis is fine with the plug reversed on the board.

My issue is the X axis. With the standard setup (plug not reversed for X) the motor homes the wrong direction. If I manually hit the endstop, the motor stops, but then manual control of the motor using +X and -X both move the same direction. Things I have tried to rectify this:

1) Change the Printer settings in Repetier for the X axis (endstop Max and back again).
2) Try the firmware settings that fixed the Y axis for the X axis (changing INVERT_X_DIR and X_HOME_DIR) individually and together.
3) I verified that the wires for both the motor and the endstop for all three axes have continuity, and that the end stops are working properly through issuing M119 after a state change.
4) I swapped the X motor and the Y motor plugs in the board. Each motor behaved the same (the X motor works fine in the Y plug and the Y motor has the problems that the X motor did). Swapping them back resumes the original behavior for each motor.
5) I replaced the X axis motor with a new one and repeated (4)
6) Turned the plug around (so it is in the same orientation as the Y motor and tried all of the above again)

Each time the motor for the X axis will either try to home in the wrong direction, or will home to the end stop, but then will not move at all in either direction after homing. The motor will try, but it sounds like it is trying to move past home and makes a terrible sound as the gear turns while the belt does not.

I did find the thread at theFrankes-dot-com that mentioned reversing values for X_MAX_PIN and X_MIN_PIN in pins.h, however
a) pins.h does not show up in Arduino 1.0.5 when Marlin.pde is open (though it is in the directory and I can edit it in Wordpad), and
b) the only variables for the axes in pins.h for the Printrboard are
#define X_STEP_PIN 0
#define X_DIR_PIN 1
#define X_ENABLE_PIN 39
and
#define X_STOP_PIN 35

This issue is consistent with all the different firmware versions I have tried. Any thoughts?

[RetireeJay]

If I understand what you've described correctly, the X motor will only move in one direction. You can reverse that direction by reversing the plug, but other than that, no matter what command you give it, it only moves one way. This behavior stays with the X motor channel on the board; it's not a function of the motor itself.

If that is correct, it sounds like the signal that's supposed to control motor direction is not reaching the motor control chip, or the motor control chip is ignoring it.

Here's a schematic of the motor control chip wiring on the Printrboard. The Atmel CPU chip is supposed to send a logic high or a logic low to the pin labeled "X_DIR" It comes out of the Atmel chip's physical pin 50, register address PA1_AD1 (although the firmware mapping is not the same and is quite convoluted).

PrintrboardStepperControllerExp.jpg

If X_DIR is changing state, but the motor always runs the same direction, then the motor controller chip is bad. If X_DIR is not changing state, then I'd say the first thing to try is re-flashing your firmware. The next thing would be to look for a short circuit that is permanently forcing the X_DIR line high or low regardless of what the firmware is telling it.

[thawkins]

I belive you will also get this stepping only in one direction only effect if one of the coils on the motor is disconnected or open. Have you tried connecting the effected motor to another channel and manualy stepping it?.

[RetireeJay]

I belive you will also get this stepping only in one direction only effect if one of the coils on the motor is disconnected or open.

Umm, no, that's not how steppers work. If you are in position 1 with coil A active, then you need to turn off coil A and turn on coil B in order to move to position 2. If you just turn off coil A, the motor won't move at all. When you reverse the direction of current to A without an intervening signal to B, then you're asking the motor to move jump by two positions (e.g. from 1 to 3), but the direction of motion will be random. I just tried this out. The motor was a lot noisier than normal, and indeed the motion created was random.

[biglazyb11]

Hi RJ and thawkins,

Thank you for the quick response. It was an older post from thawkins that had me checking all the wires on all the motors -- I was hopeful that I just had a bad wire, which is why the motor was behaving so strangely. When they all checked out, I swapped the Y motor and the X motor as mentioned previously, and each performed as expected (the X motor plugged into Y worked normally, the Y motor plugged into X had the same problems that the X motor did previously). I think RJ is correct in that it is a board issue, not a motor issue. Interestingly enough, the motor control wires show continuity in pairs as well as with individual wires (1 -> 1 is continuous, 1 -> 2 is continuous, 2 -> 2 and 2 -> 1 are also continuous -- the same relationships exist for 3 & 4).

I have flashed the firmware on the board about two dozen times in the last day or so hoping to resolve this -- when I get home tonight I will look for a short as you mention at the X_DIR pin. Is there a Gcode command I can enter that will echo the current state of X_DIR when I move the motor?

Thank you
Brian