Z Axis getting stuck with Marlin 1.1.0-RC7

  • Background:

    I just successfully installed a RepRapDiscount Full Graphic Display on my Prusa i3; and in doing so, I've upgraded all of the firmware to the latest version of Marlin, 1.1.0-RC7. With my previous version of Marlin, 1.0.2-1, everything was working perfectly. I've transferred every parameter over from my older version to my newer one. There were some aspects of code that were written differently, but essentially everything works except the Z-Axis.


    The one issue that I seem to be having is with any kind of movement with the Z-Axis. When it moves, whether from the LCD or Repetier, it appears to accelerate as it is supposed to, but then gets stuck/skips a bunch of steps, and then decelerates slowly as it's supposed to. Regardless of the distance I instruct it to move, it will accelerate normally for the same amount of time/distance/steps, go into this unholy mode for a period of time/distance/steps relative to what it was instructed, and then smoothly decelerates for the exact same amount of time every time. For example, if it is supposed to move 10000 steps, it will move 100 steps smoothly, then skip for 9800 steps, and finish with another 100 steps smoothly. If, for example, it needs to move 5000 steps, it will also move 100 steps smoothly, then skip for 4800 steps, and finish smoothly the last 100 steps. Keep in mind, these numbers are completely drawn from space; they are not accurate by any stretch of the imagination. I'm just trying to paint as clear of a picture as possible.


    At first I checked to make sure everything is mechanically sound.

    • The nuts move freely up and down the 5mm threaded rod. There are no points along the entire length of the rod that the nuts don't move very freely.

    • The stainless steel rods are well aligned and the entire Z/X-Axis carriage moves very freely along the vertical rails. The bearings appear to be fine.

    I then wanted to narrow it down to being the firmware, and not electrical. For the record, maybe I'm missing something obvious, so please let me know.

    • I measured the voltage on my A4988 stepper drivers on the RAMPS 1.4 board, sitting on the Arduino Mega2560 R3, and it is reading 350mV. Even if I adjust the potentiometer to 550mV, I still get the same issue.

    • The jumpers underneath seem to be snugly in place, and all the pins on the A4988 appear to be fine as well.

    • The one thing I haven't checked in the section, logically analyzing, is the wires going from the board to the motors themselves, but based on the following, I don't believe that is the issue. (Although I have been wrong before)

    Moving onto the firmware.

    I've played around with the default settings section in Configuration.h with no avail. Regardless of how low, or high, I go with any of the max acceleration settings, I cannot seem to fix the problem. It accelerates slower, but the overall effect is the same.

    #define DEFAULT_AXIS_STEPS_PER_UNIT   {80,80,3840,90}
    #define DEFAULT_MAX_FEEDRATE {500, 500, 5, 25}
    #define DEFAULT_MAX_ACCELERATION {2000,2000,10,2000}
    #define DEFAULT_XYJERK 20.0
    #define DEFAULT_ZJERK 0.4
    #define DEFAULT_EJERK 5.0


    At this point, if I had to guess, it has something to do with the maximum speed setting, or the microstepping. These are some of the settings that I have on the new firmware.

    #define MANUAL_FEEDRATE {50*60, 50*60, 4*60, 60} // Feedrates for manual moves along X, Y, Z, E from panel
    #define ULTIPANEL_FEEDMULTIPLY // Comment to disable setting feedrate multiplier via encoder

    // minimum time in microseconds that a movement needs to take if the buffer is emptied.

    // If defined the movements slow down when the look ahead buffer is only half full
    #define SLOWDOWN

    // Frequency limit
    // See nophead's blog for more info
    // Not working O
    //#define XY_FREQUENCY_LIMIT 15

    // Minimum planner junction speed. Sets the default minimum speed the planner plans for at the end
    // of the buffer and all stops. This should not be much greater than zero and should only be changed
    // if unwanted behavior is observed on a user's machine when running at very slow speeds.
    #define MINIMUM_PLANNER_SPEED 0.05// (mm/sec)

    // Microstep setting (Only functional when stepper driver microstep pins are connected to MCU.
    #define MICROSTEP_MODES {16,16,16,16,16} // [1,2,4,8,16]

    // Motor Current setting (Only functional when motor driver current ref pins are connected to a digital trimpot on supported boards)
    #define DIGIPOT_MOTOR_CURRENT {135,135,135,135,135} // Values 0-255 (RAMBO 135 = ~0.75A, 185 = ~1A)

    // Motor Current controlled via PWM (Overridable on supported boards with PWM-driven motor driver current)
    //#define PWM_MOTOR_CURRENT {1300, 1300, 1250} // Values in milliamps

    // uncomment to enable an I2C based DIGIPOT like on the Azteeg X3 Pro
    //#define DIGIPOT_I2C
    // Number of channels available for I2C digipot, For Azteeg X3 Pro we have 8
    // actual motor currents in Amps, need as many here as DIGIPOT_I2C_NUM_CHANNELS
    #define DIGIPOT_I2C_MOTOR_CURRENTS {1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0}


    If anybody could help me, or even point me in the right direction, I would really appreciate it. I'm getting desperate with this new firmware version. It has all these conditional tabs that didn't exist in my other one, and I can't quite figure it out.

  • The problem is likely in the MAX_FEEDRATE. Initially the moves are smooth, indicating that acceleration is not a problem. However, you have your maximum speed set to 5mm/s, which, for m5 threaded rod (with 0.5mm pitch), translates to 10 revolusions/second for the threaded rod. That is quite fast, and the stepper probably can't keep up. Try reducing the feedrate.

    The firmware microstepping and current settings have absolutely nothing to do with it, since these are not supported on your setup (which has physical potentiometers and microstepping jumpers).

    This was exactly the issue! Thank you so much!

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM