<p>So after 5 days of trouble shooting, Bob-the-Kuhn over on the marlin github forum solved it for, anyone else who faces the same issue can head over to github for my solutions.</p>
<p><a href="https://github.com/MarlinFirmware/Marlin/issues/9287#issuecomment-359428147" rel="nofollow noreferrer">https://github.com/MarlinFirmware/Marlin/issues/9287#issuecomment-359428147</a></p>
<p>Conversation from link:</p>
<blockquote>
<p><strong>Bob-the-Kun:</strong>
Problem does not follow the driver. Problem does not follow the
steppers.</p>
<p>I'm thinking that the Z socket has a problem. Sounds like an open/poor
contact.</p>
<p>Try bending the DIRECTION lead on the Z driver a little and see if the
problem disappears. It's one of the corner pins. Sometimes it's called
DIR. If your driver's pins aren't labeled then bend all four corner
pins a little.</p>
<p>Another option is to move the Z function to the E1 socket. Replace
your pins_RAMPS.h file with this one. pins_RAMPS.zip</p>
<p>FYI - if this really is a hardware problem then it's the second RAMPS
hardware problem within a week. Most unusual.</p>
<p><strong>Post reply:</strong></p>
<p>Yes the socket I am now assuming is just broken (not sure what exactly
but possibly one of the connections), After using for pins_RAMPS file
and changed the motors back to series and connected to the E1 slot I
successful got the printer to work!!! Thank you very much Z axis is
working as I would expect! I am now calibrating the printer as it
definitely needs it.</p>
</blockquote>

CC BY-SA 3.0
2018-01-23T22:32:05.233Z
It's great that you took the time to come back and share that you solved the problem.  It's sub-optimal - though - that you just put a link.  Stuff changes / get moved / is deleted from the internet, and the risk is the link will break at some point in the future.  It would be great if you could al least add a summary of what the solution is all about. :)
mac
CC BY-SA 4.0
2018-01-23T06:26:02.883Z
2018-08-04T23:00:33.810Z
2020-06-18T08:29:41.667Z
Bobby McGlone
<p>I have been searching around the internet for the last 3 days trying to figure this out. My Z axis motors for a pursa-i3 3d printer are not working correctly. I have marlin firmware and using repetier host. I send a command to move the z axis and I get it to move, however I if I send the same command again the motors will sometimes spin the other way. feel like They almost randomly choose which direction they turn.</p>

<p>As I said I have been trouble shooting this for a while now. What I am suspecting is the firmware feedrates and acceleration or some setting is not correct. </p>

<p>Here is my code:</p>

<pre><code>//// MOVEMENT SETTINGS
#define NUM_AXIS 4 // The axis order in all axis related arrays is X, Y, Z, E
#define HOMING_FEEDRATE {50*60, 50*60, 2*60, 0}  // set the homing speeds (mm/min)

#define DEFAULT_AXIS_STEPS_PER_UNIT   {80,80,4000,590}  
#define DEFAULT_MAX_FEEDRATE          {300, 300, 3, 45}    // (mm/sec)
#define DEFAULT_MAX_ACCELERATION      {1000,1000,50,500}    // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for Skeinforge 40+, for older versions raise them a lot.

#define DEFAULT_ACCELERATION          1000    // X, Y, Z and E max acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION  1000   // X, Y, Z and E max acceleration in mm/s^2 for retracts

#define DEFAULT_XYJERK                10   // (mm/sec)
#define DEFAULT_ZJERK                 0.3     // (mm/sec)
#define DEFAULT_EJERK                 5.0    // (mm/sec)
</code></pre>

<p>I tried swapping the drivers around and the motors will work perfectly on another axis so I don't suspect it to be a driver issue. I have been turning the pots ontop of the drivers to make them work but can't make them to go the same direction i want them to.</p>

<p>I've checked the wires and I almost sure they are wired up correctly. (could be wrong but have checked it over with a multimeter.)</p>

<p>I am new to this and it's my first time building one of these would appreciate any help I can get and and maybe I have over looked something I have tested.
Just really want the axis to move in the direction That I say it to move in.</p>

<hr>

<p>More details about my setup is: A Robocraze 3D Printer Controller Board RAMPS 1.4 using A4988 stepper motors drivers and my motors are the nema 17 stepper motors. I currently have the two z axis motors wired in parallel but have tried before using series, however the problem of being unable to control the direction of the Z motors still arises (can easily switch back to series). </p>

<p>currently trying with no load just to get the motors turn in the correct direction when I send a G-code command. I am using Repetier host on ubuntu 14.04.5.</p>

<p>I have also check the endstops and they are working perfectly, so they ain't a problem (I don't think :p)</p>

<p>Thank you,
Bobby</p>

CC BY-SA 3.0
2018-01-20T06:50:33.017Z
Not sure if I asked a clear enough question, hoping for some help and can provide more details if needed?
Bobby McGlone
CC BY-SA 3.0
2018-01-20T16:52:26.303Z
Try adding more specifics on your wiring, the servos you use, etc. There is something not completely obvious going on here.
Sean Houlihane
CC BY-SA 3.0
2018-01-22T04:24:02.053Z
Added a few more details and yeah I can understand :(, hoping someone has faced the same issue?  really odd because when I send the exact same g-code command repeatedly The Z axis will turn back and forth clockwise then Anti clockwise with each different command! Such a headache hahaha, Thank you
Bobby McGlone
CC BY-SA 3.0
2018-01-22T08:52:55.883Z
Did you try with just one of the motors connected? What if you disconnect the motor coupling? You need to isolate electronic/software and mechanical issues as the potential cause.
Sean Houlihane
CC BY-SA 3.0
2018-01-22T10:02:36.050Z
Hello, Yes I have tried with just one motor connected to the Z driver and still same issue, even different motors completely. I know it is something that is wrong with the Z pins, driver or firmware (feed rates as such are different). I have tried swapping the drivers and it works in other slots for the x,y or extruder motors, so i don't think the driver is the problem. Could be maybe the RAMPS board slot for the Z motors is faulty? I am guessing that since no one has jumped up and said anything about the code, the firmware is fine? so it must be the RAMPS board Z driver socket???
Bobby McGlone
<diy-3d-printer><reprap><ramps-1.4><z-axis>
Z axis Stepper motors not working correctly
Bobby McGlone
# Z axis Stepper motors not working correctly

(Asked by: username_0 on 2018-01-20)

I have been searching around the internet for the last 3 days trying to figure this out. My Z axis motors for a pursa-i3 3d printer are not working correctly. I have marlin firmware and using repetier host. I send a command to move the z axis and I get it to move, however I if I send the same command again the motors will sometimes spin the other way. feel like They almost randomly choose which direction they turn.
As I said I have been trouble shooting this for a while now. What I am suspecting is the firmware feedrates and acceleration or some setting is not correct. 
Here is my code:
//// MOVEMENT SETTINGS
#define NUM_AXIS 4 // The axis order in all axis related arrays is X, Y, Z, E
#define HOMING_FEEDRATE {50*60, 50*60, 2*60, 0}  // set the homing speeds (mm/min)

#define DEFAULT_AXIS_STEPS_PER_UNIT   {80,80,4000,590}  
#define DEFAULT_MAX_FEEDRATE          {300, 300, 3, 45}    // (mm/sec)
#define DEFAULT_MAX_ACCELERATION      {1000,1000,50,500}    // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for Skeinforge 40+, for older versions raise them a lot.

#define DEFAULT_ACCELERATION          1000    // X, Y, Z and E max acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION  1000   // X, Y, Z and E max acceleration in mm/s^2 for retracts

#define DEFAULT_XYJERK                10   // (mm/sec)
#define DEFAULT_ZJERK                 0.3     // (mm/sec)
#define DEFAULT_EJERK                 5.0    // (mm/sec)

I tried swapping the drivers around and the motors will work perfectly on another axis so I don't suspect it to be a driver issue. I have been turning the pots ontop of the drivers to make them work but can't make them to go the same direction i want them to.
I've checked the wires and I almost sure they are wired up correctly. (could be wrong but have checked it over with a multimeter.)
I am new to this and it's my first time building one of these would appreciate any help I can get and and maybe I have over looked something I have tested.
Just really want the axis to move in the direction That I say it to move in.

More details about my setup is: A Robocraze 3D Printer Controller Board RAMPS 1.4 using A4988 stepper motors drivers and my motors are the nema 17 stepper motors. I currently have the two z axis motors wired in parallel but have tried before using series, however the problem of being unable to control the direction of the Z motors still arises (can easily switch back to series). 
currently trying with no load just to get the motors turn in the correct direction when I send a G-code command. I am using Repetier host on ubuntu 14.04.5.
I have also check the endstops and they are working perfectly, so they ain't a problem (I don't think :p)
Thank you,
Bobby

**Tags:** diy-3d-printer, reprap, ramps-1.4, z-axis
> **Comments:**
> **username_0**: Not sure if I asked a clear enough question, hoping for some help and can provide more details if needed?  
> **username_1**: Try adding more specifics on your wiring, the servos you use, etc. There is something not completely obvious going on here.  
> **username_0**: Added a few more details and yeah I can understand :(, hoping someone has faced the same issue?  really odd because when I send the exact same g-code command repeatedly The Z axis will turn back and forth clockwise then Anti clockwise with each different command! Such a headache hahaha, Thank you  
> **username_1**: Did you try with just one of the motors connected? What if you disconnect the motor coupling? You need to isolate electronic/software and mechanical issues as the potential cause.  
> **username_0**: Hello, Yes I have tried with just one motor connected to the Z driver and still same issue, even different motors completely. I know it is something that is wrong with the Z pins, driver or firmware (feed rates as such are different). I have tried swapping the drivers and it works in other slots for the x,y or extruder motors, so i don't think the driver is the problem. Could be maybe the RAMPS board slot for the Z motors is faulty? I am guessing that since no one has jumped up and said anything about the code, the firmware is fine? so it must be the RAMPS board Z driver socket???  

---

## 1 answers

### Answer by username_0 on 2018-01-23. Score: 1 | Accepted answer

So after 5 days of trouble shooting, Bob-the-Kuhn over on the marlin github forum solved it for, anyone else who faces the same issue can head over to github for my solutions.

<https://github.com/MarlinFirmware/Marlin/issues/9287#issuecomment-359428147>

Conversation from link:

> **Bob-the-Kun:**
> Problem does not follow the driver. Problem does not follow the
> steppers.
>
> I'm thinking that the Z socket has a problem. Sounds like an open/poor
> contact.
>
> Try bending the DIRECTION lead on the Z driver a little and see if the
> problem disappears. It's one of the corner pins. Sometimes it's called
> DIR. If your driver's pins aren't labeled then bend all four corner
> pins a little.
>
> Another option is to move the Z function to the E1 socket. Replace
> your pins\_RAMPS.h file with this one. pins\_RAMPS.zip
>
> FYI - if this really is a hardware problem then it's the second RAMPS
> hardware problem within a week. Most unusual.
>
> **Post reply:**
>
> Yes the socket I am now assuming is just broken (not sure what exactly
> but possibly one of the connections), After using for pins\_RAMPS file
> and changed the motors back to series and connected to the E1 slot I
> successful got the printer to work!!! Thank you very much Z axis is
> working as I would expect! I am now calibrating the printer as it
> definitely needs it.

> **Comments:**
> **username_2**: It's great that you took the time to come back and share that you solved the problem.  It's sub-optimal - though - that you just put a link.  Stuff changes / get moved / is deleted from the internet, and the risk is the link will break at some point in the future.  It would be great if you could al least add a summary of what the solution is all about. :)  

---

