<p>I've replaced the Z-axis stepper driver with an off-board Pololu-style A4988 driver by soldering leads to pins 2 and 3 on the Melzi board, then connecting those to the driver on a separate board. The Z-axis now moves correctly. When I encountered issues with the step pin (pin 3), I connected it to pin 12 (bed heater) instead, leaving the bed to be heated manually. This has worked so far and the only problems I've encountered were minor issues with electrical noise, which I was able to fix with a shielded cable.</p>

CC BY-SA 4.0
2021-02-14T02:45:04.583Z
2021-02-22T18:57:02.947Z
2021-02-22T18:57:02.947Z
malachik
<p>I'm setting up a replacement Melzi 2.0 board from TRONXY for my i3 clone (a Monoprice Maker Select v2 for those curious), which according to the <a href="https://reprap.org/wiki/Melzi#Melzi_Version_2.0" rel="nofollow noreferrer">RepRap wiki</a> has A4982 drivers for all the steppers. I'm attempting to configure Marlin 2.0.x for this printer and this is the last big problem I'm encountering.</p>
<p>The problem: The Z-axis (or any motors connected to the Z-axis driver) won't budge no matter what I try. All my other steppers work fine.</p>
<p>What I've tried: I've done everything I can to prompt the Z-axis to move, from Gcode commands to homing via the LCD and Pronterface. I've connected my X-axis motor to the Z-axis driver and it won't move either. Sometimes, when I send a command for them to move, they'll make a small noise - like they're getting power - but won't move. I probed the motor connectors at the board and received nothing but a few stray millivolts here and there, very different from the several volts on my Y-axis motor when I did the same thing. Bear in mind, that was just one test moving them from the LCD, and this time they did not make any noise or attempt to move. I have switched pin definitions in the firmware for X/Z ENABLE/STEP/DIR and the Z driver once again appeared to be the culprit, keeping the Z-axis planted even if it was being controlled as if it were the X-axis.</p>
<p>What I think the problem could be: To me, this seems like a software problem. I'm configuring Marlin for my first time and I think I messed something up somewhere. Could it be a problem with the trim pots, motor currents, motor enabling, or something else? Outside of that, maybe the driver is just dead?</p>
<p>My Marlin 2.0.x config.h for reference:</p>
<pre><code>// These are all excerpts from various parts of Configuration.h

#define DEFAULT_AXIS_STEPS_PER_UNIT   { 80, 80, 400, 500 }

#define DEFAULT_MAX_FEEDRATE          { 300, 300, 4, 25 }

#define DEFAULT_MAX_ACCELERATION      { 3000, 3000, 100, 10000 }

#define DEFAULT_ACCELERATION          2800    // X, Y, Z and E acceleration for printing moves
#define DEFAULT_RETRACT_ACCELERATION  2800    // E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION   2800    // X, Y, Z acceleration for travel (non printing) moves

//#define CLASSIC_JERK  //left at default

// :{ 0:'Low', 1:'High' }
#define X_ENABLE_ON 0
#define Y_ENABLE_ON 0
#define Z_ENABLE_ON 0
#define E_ENABLE_ON 0 // For all extruders

#define DISABLE_X false
#define DISABLE_Y false
#define DISABLE_Z false

#define INVERT_X_DIR false
#define INVERT_Y_DIR false
#define INVERT_Z_DIR false

#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

#define X_MIN_POS 0
#define Y_MIN_POS 0
#define Z_MIN_POS 0
#define X_MAX_POS X_BED_SIZE
#define Y_MAX_POS Y_BED_SIZE
#define Z_MAX_POS 150

#define MIN_SOFTWARE_ENDSTOPS
#if ENABLED(MIN_SOFTWARE_ENDSTOPS)
  #define MIN_SOFTWARE_ENDSTOP_X
  #define MIN_SOFTWARE_ENDSTOP_Y
  //#define MIN_SOFTWARE_ENDSTOP_Z    //disabled until the driver works correctly
#endif

#define MAX_SOFTWARE_ENDSTOPS
#if ENABLED(MAX_SOFTWARE_ENDSTOPS)
  #define MAX_SOFTWARE_ENDSTOP_X
  #define MAX_SOFTWARE_ENDSTOP_Y
  //#define MAX_SOFTWARE_ENDSTOP_Z
#endif

//#define Z_SAFE_HOMING

#if ENABLED(Z_SAFE_HOMING)
  #define Z_SAFE_HOMING_X_POINT X_CENTER  // X point for Z homing
  #define Z_SAFE_HOMING_Y_POINT Y_CENTER  // Y point for Z homing
#endif

// Homing speeds (mm/min)
#define HOMING_FEEDRATE_XY (50*50) //changed from 3000 to 2500
#define HOMING_FEEDRATE_Z  (4*60)

// Validate that endstops are triggered on homing moves
#define VALIDATE_HOMING_ENDSTOPS

// Sorry if that was a bit much, I tried to include all the settings that could 
// potentially have an effect on the Z motion.
</code></pre>
<p>I genuinely have no idea where to even look to solve this problem, so any guidance or advice would be hugely appreciated!! Thanks!</p>
<p>My conclusion is that the driver chip itself is dead and replacing it ought to fix the problem. If this works, I will post an answer to this question.</p>

CC BY-SA 4.0
2021-02-06T23:40:15.373Z
Hi! If X,Y are working ok, then maybe try to swap stepper PINs (`ENABLE`, `DIR`, `STEP`) of Z and e.g. Y in firmware configuration for a while, and try to manually move (LCD or G-code)  the Y and Z axes a bit ? (Better swap also endstops if you are going to home, etc.). Then you will know much better if this is really a software problem.
octopus8
CC BY-SA 4.0
2021-02-07T23:27:45.923Z
Hi, I've now tried modifying all of those parameters for the Z-axis, and nothing has seemed to influence it whatsoever. I've continued to probe the steppers and still haven't seen any signal at all. I think the problem is either somewhere deep in software, or that the driver itself is bad somehow.
malachik
CC BY-SA 4.0
2021-02-08T04:59:46.107Z
My excuses, but I do not understand precisely what you did... What I have proposed is a visual test, it has nothing for probing. The goal is to exchange purpose of two physical drivers: Z and Y (or any driver that works OK). So (1) did you swap respective pin values of Z and Y in your board's settings (some Marlin file) and reinstall? (2) After this swap, if it still caused one stepper moving and the other one stalled? (3) Resolve: if stalled motor was connected to driver marked "Z" on the board, then it is hardware issue. If it was connected to driver with "Y" mark, then it is software issue.
octopus8
CC BY-SA 4.0
2021-02-08T05:12:22.617Z
( If you got firmware settings from reliable source, then it is less of chance - but there is another possibility for "Z" variant: that pin values originally set for Z driver in your firmware's files were incorrect from beggining. Then signals from microprocessor would go via unconnected legs and arrive nowhere. Or arrive elsewhere - you may want to doublecheck in settings if these pins are not used for any other purpose. )
octopus8
CC BY-SA 4.0
2021-02-08T07:14:32.733Z
You probably know this, but the default Marlin configuration is not to move E unless the extruder temperature is at a minimum value.
DoxyLover
CC BY-SA 4.0
2021-02-08T22:47:26.493Z
@octopus8 My apologies, I misread your comment the first time. I have now swapped the pin definitions for the X and Z axis. The X-axis happily moved as if it was Z and the actual Z axis refused to move once again. My conclusion is that I will need to buy a new driver and connect it in place of the current driver. Thank you for your help!
malachik
<marlin><z-axis><stepper-driver><melzi>
Z-Axis on i3 clone won't move at all, Melzi A4982 driver problem
malachik
# Z-Axis on i3 clone won't move at all, Melzi A4982 driver problem

(Asked by: username_0 on 2021-02-06)

I'm setting up a replacement Melzi 2.0 board from TRONXY for my i3 clone (a Monoprice Maker Select v2 for those curious), which according to the RepRap wiki has A4982 drivers for all the steppers. I'm attempting to configure Marlin 2.0.x for this printer and this is the last big problem I'm encountering.
The problem: The Z-axis (or any motors connected to the Z-axis driver) won't budge no matter what I try. All my other steppers work fine.
What I've tried: I've done everything I can to prompt the Z-axis to move, from Gcode commands to homing via the LCD and Pronterface. I've connected my X-axis motor to the Z-axis driver and it won't move either. Sometimes, when I send a command for them to move, they'll make a small noise - like they're getting power - but won't move. I probed the motor connectors at the board and received nothing but a few stray millivolts here and there, very different from the several volts on my Y-axis motor when I did the same thing. Bear in mind, that was just one test moving them from the LCD, and this time they did not make any noise or attempt to move. I have switched pin definitions in the firmware for X/Z ENABLE/STEP/DIR and the Z driver once again appeared to be the culprit, keeping the Z-axis planted even if it was being controlled as if it were the X-axis.
What I think the problem could be: To me, this seems like a software problem. I'm configuring Marlin for my first time and I think I messed something up somewhere. Could it be a problem with the trim pots, motor currents, motor enabling, or something else? Outside of that, maybe the driver is just dead?
My Marlin 2.0.x config.h for reference:
// These are all excerpts from various parts of Configuration.h

#define DEFAULT_AXIS_STEPS_PER_UNIT   { 80, 80, 400, 500 }

#define DEFAULT_MAX_FEEDRATE          { 300, 300, 4, 25 }

#define DEFAULT_MAX_ACCELERATION      { 3000, 3000, 100, 10000 }

#define DEFAULT_ACCELERATION          2800    // X, Y, Z and E acceleration for printing moves
#define DEFAULT_RETRACT_ACCELERATION  2800    // E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION   2800    // X, Y, Z acceleration for travel (non printing) moves

//#define CLASSIC_JERK  //left at default

// :{ 0:'Low', 1:'High' }
#define X_ENABLE_ON 0
#define Y_ENABLE_ON 0
#define Z_ENABLE_ON 0
#define E_ENABLE_ON 0 // For all extruders

#define DISABLE_X false
#define DISABLE_Y false
#define DISABLE_Z false

#define INVERT_X_DIR false
#define INVERT_Y_DIR false
#define INVERT_Z_DIR false

#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

#define X_MIN_POS 0
#define Y_MIN_POS 0
#define Z_MIN_POS 0
#define X_MAX_POS X_BED_SIZE
#define Y_MAX_POS Y_BED_SIZE
#define Z_MAX_POS 150

#define MIN_SOFTWARE_ENDSTOPS
#if ENABLED(MIN_SOFTWARE_ENDSTOPS)
  #define MIN_SOFTWARE_ENDSTOP_X
  #define MIN_SOFTWARE_ENDSTOP_Y
  //#define MIN_SOFTWARE_ENDSTOP_Z    //disabled until the driver works correctly
#endif

#define MAX_SOFTWARE_ENDSTOPS
#if ENABLED(MAX_SOFTWARE_ENDSTOPS)
  #define MAX_SOFTWARE_ENDSTOP_X
  #define MAX_SOFTWARE_ENDSTOP_Y
  //#define MAX_SOFTWARE_ENDSTOP_Z
#endif

//#define Z_SAFE_HOMING

#if ENABLED(Z_SAFE_HOMING)
  #define Z_SAFE_HOMING_X_POINT X_CENTER  // X point for Z homing
  #define Z_SAFE_HOMING_Y_POINT Y_CENTER  // Y point for Z homing
#endif

// Homing speeds (mm/min)
#define HOMING_FEEDRATE_XY (50*50) //changed from 3000 to 2500
#define HOMING_FEEDRATE_Z  (4*60)

// Validate that endstops are triggered on homing moves
#define VALIDATE_HOMING_ENDSTOPS

// Sorry if that was a bit much, I tried to include all the settings that could 
// potentially have an effect on the Z motion.

I genuinely have no idea where to even look to solve this problem, so any guidance or advice would be hugely appreciated!! Thanks!
My conclusion is that the driver chip itself is dead and replacing it ought to fix the problem. If this works, I will post an answer to this question.

**Tags:** marlin, z-axis, stepper-driver, melzi
> **Comments:**
> **username_1**: Hi! If X,Y are working ok, then maybe try to swap stepper PINs (`ENABLE`, `DIR`, `STEP`) of Z and e.g. Y in firmware configuration for a while, and try to manually move (LCD or G-code)  the Y and Z axes a bit ? (Better swap also endstops if you are going to home, etc.). Then you will know much better if this is really a software problem.  
> **username_0**: Hi, I've now tried modifying all of those parameters for the Z-axis, and nothing has seemed to influence it whatsoever. I've continued to probe the steppers and still haven't seen any signal at all. I think the problem is either somewhere deep in software, or that the driver itself is bad somehow.  
> **username_1**: My excuses, but I do not understand precisely what you did... What I have proposed is a visual test, it has nothing for probing. The goal is to exchange purpose of two physical drivers: Z and Y (or any driver that works OK). So (1) did you swap respective pin values of Z and Y in your board's settings (some Marlin file) and reinstall? (2) After this swap, if it still caused one stepper moving and the other one stalled? (3) Resolve: if stalled motor was connected to driver marked "Z" on the board, then it is hardware issue. If it was connected to driver with "Y" mark, then it is software issue.  
> **username_1**: ( If you got firmware settings from reliable source, then it is less of chance - but there is another possibility for "Z" variant: that pin values originally set for Z driver in your firmware's files were incorrect from beggining. Then signals from microprocessor would go via unconnected legs and arrive nowhere. Or arrive elsewhere - you may want to doublecheck in settings if these pins are not used for any other purpose. )  
> **username_2**: You probably know this, but the default Marlin configuration is not to move E unless the extruder temperature is at a minimum value.  
> **username_0**: @octopus8 My apologies, I misread your comment the first time. I have now swapped the pin definitions for the X and Z axis. The X-axis happily moved as if it was Z and the actual Z axis refused to move once again. My conclusion is that I will need to buy a new driver and connect it in place of the current driver. Thank you for your help!  

---

## 1 answers

### Answer by username_0 on 2021-02-14. Score: 1 | Accepted answer

I've replaced the Z-axis stepper driver with an off-board Pololu-style A4988 driver by soldering leads to pins 2 and 3 on the Melzi board, then connecting those to the driver on a separate board. The Z-axis now moves correctly. When I encountered issues with the step pin (pin 3), I connected it to pin 12 (bed heater) instead, leaving the bed to be heated manually. This has worked so far and the only problems I've encountered were minor issues with electrical noise, which I was able to fix with a shielded cable.


---

