Z Axis getting stuck with Marlin 1.1.0-RC7

Alex Sky
  • Z Axis getting stuck with Marlin 1.1.0-RC7 Alex Sky

    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.

    Problem:

    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.

    Troubleshooting:

    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_ACCELERATION          1000
    #define DEFAULT_RETRACT_ACCELERATION  1000
    #define DEFAULT_TRAVEL_ACCELERATION   1000
    #define DEFAULT_XYJERK                20.0
    #define DEFAULT_ZJERK                 0.4
    #define DEFAULT_EJERK                 5.0
    

    Theory:

    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.

    #if ENABLED(ULTIPANEL)
    #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
    #endif
    
    // minimum time in microseconds that a movement needs to take if the buffer is emptied.
    #define DEFAULT_MINSEGMENTTIME        20000
    
    // 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
    #define DIGIPOT_I2C_NUM_CHANNELS 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}
    

    Solution:

    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).

Tags
prusa-i3 marlin firmware z-axis
Related questions and answers
  • T3000.00 echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s) echo: M205...I have a RAMPS 1.4 and an Arduino Mega 2560. The problem is with 100k NTC thermistor. I've tested it with a multimeter, it results in ~122kΩ. I am using Marlin 1.0.2 (latest stable). I am... woking completely. I had configured the LCD (ReprapDiscount Smart Controller) and all the steppers were working. Right now, it does not even sends self test to Pronterface upon start/connection

  • very well until it started giving the same problem as the first Arduino board. Someone can tell me if I have done something wrong, or is it the RAMPS board that does not work properly? EDIT: I read...This is my problem: I'm assembling a 3D printer with the RAMPS 1.4 board and Arduino Mega. I have assembled the structure and the electronics (set drivers, placed the jumpers, connected stepper motors...) and have uploaded Marlin firmware (configuring: thermistor, endstops...) on the Arduino Mega. I've tried to connect, via USB, to the computer and using the Repetier software I have commanded

  • I have an old Solidoodle 2 that I bought broken from a garage sale that I am converting to use RAMPS 1.4 with Marlin Firmware. All the motors work correctly, I am just having issues getting... the logic of the endstop. #define Z_MIN_PROBE_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop. I have X-min enabled and inverted. When I send an M119 (endstop status code) I recieve: Send: M119 Recv: Reporting endstop status Recv: x_min: open Recv: y_min: TRIGGERED Recv: z_min: TRIGGERED And then when I press down the X endstop with my hand I get: Send: M119 Recv

  • I am working on a Python code (below) that accelerates a stepper motor until it reaches a specific amount of steps. for s in range (steps): if s < accelerationsteps: lateststep = self.onestep... 0.5) aend = speed at which the acceleration should stop (for example 0.05) accelerationsteps = amount of steps over which the acceleration should happen The problem is that the velocity increases... achieve a linear increase with a stepper motor but I have not managed to translate that into my python code. I would highly appreciate it if someone could help me with this and I think it would

  • turn the fan on at 100%). This command had no results. The firmware is stock (Marlin), all exposed cables seem intact and without damage, and the plug to the control board seems to be fine. Maybe I...SOLVED: I replaced the leads coming from the fan motor and it is working just fine. Thanks for the input. If anyone else has this model, I would suggest printing and installing a wire clip in order... and the fan doesn't move. I tested the current on another 12V fan laying around and that fan runs just fine. So, it seems that the fan has gone bad...somehow. I am still quite confused on how

  • issue. I'm fairly new to this; I rather not brick my printer, and I haven't found any good guides to installing firmware on the device either. I'm not convinced this is the right option. Should I..., I'm only reading 102-104°C. I've checked these values with the bare aluminum build plate, and I've allowed the temps to stabilize for at least 10 minutes to ensure that I have consistent readings... like the option to get above 100°C bed temp. Am I on the right track? Suggestions? I'm still pretty new to the device and 3D printing in general, so I may have overlooked something obvious. Update

  • values affect the move time: How should Acceleration and Jerk be considered; and, how do they speed up or slow down the print time? How should I edit my formula in order to include Acceleration...: It scans the entire G-code file to identify all of the movements It calculates the time for each move by dividing segment distance by the speed in mm/s. Let's assume this is the G-code: G28... / mmPerSecond By summing up all the move times, we have the total estimated print time. I've seen that some forums state that the 3D print time also depends on some settings on the 3D printer, especially

  • 20x20 cm bed. The other X and Z axes are OK. So, I have played with the #defines explained below, but I couldn't even make any single mm difference by homing. They are all ignored when the printer is homing. It goes and rests on the hardware end-stops and stops there eventually. All I want 10 mm offset for Y axis. Started with this; // Travel limits after homing #define X_MAX_POS 200 #define..._HOME_POS 0 #define MANUAL_Y_HOME_POS 10 <<< (tested with 10 or -10) #define MANUAL_Z_HOME_POS 0 I have also played with the slicer tool (Repetier) settings where homing related values

  • Marlin Adjusting feedrate make it happen

    the feedrate for speed along the xy axis whilst the printer is in operation to make sure the printer stops on time and prints accurately. I have some code for controlling the feedrate but the problem is that I'm not sure where I am supposed make these adjustments. In the configuration.h file I see this code: (lines 742 and 753 ) /*line 742*/ #define HOMING_FEEDRATE_XY (50*60) /*line 753*/ #define DEFAULT_MAX_FEEDRATE {300, 300, 5, 25} // (mm/sec) I'm probably misunderstanding something but it seems like this sets the feedrate to a default value which is the same as the maximum

Data information