Close



Page 1 of 6 123 ... LastLast
Results 1 to 10 of 55
  1. #1
    Staff Engineer printbus's Avatar
    Join Date
    May 2014
    Location
    Highlands Ranch, Colorado USA
    Posts
    1,437
    Add printbus on Thingiverse

    Marlin Motion Related Configuration.h Settings for MakerFarm i3v

    I'm finally finding time to experiment with different motion settings (feedrates, acceleration, etc.) for my i3v-8 (8-inch i3v). It'd be great to find that magic sweet spot of settings that prints reasonably fast while still providing fairly decent print quality. In experimenting with settings, I'm getting everything from inconsistent results to results that are suspect to be dependent on filament temp/liquidity, print weight on the bed, etc.

    Anyone care to share how they've adjusted the Marlin motion settings from the MakerFarm defaults? What was the rationale/benefit of the changes, and how extensively do you believe the changes were a good thing?

    Examples of motion related settings include:
    HOMING_FEEDRATE {X,Y,Z,E}
    DEFAULT_MAX_FEEDRATE {X,Y,Z,E}
    DEFAULT_MAX_ACCELERATION {X,Y,Z,E}
    DEFAULT_ACCELERATION
    DEFAULT_RETRACT_ACCELERATION
    DEFAULT_XYJERK
    DEFAULT_ZJERK
    DEFAULT_EJERK

    DEFAULT_AXIS_STEPS_PER_UNIT {X,Y,Z,E} is another motion setting but X,Y, Z are fixed by the hardware design and E is something we all typically calibrate

    For completeness, we should probably include MANUAL_FEEDRATE{X,Y,Z,E} from configuration_adv.h, but I don't know that there is much to discuss with it. The stated intent is that these are the feed rates used during axis moves requested from the LCD panel. The way the code seems to work, however, it seems more accurate to say that you can use MANUAL_FEEDRATE to set manual move speeds that are slower than those in DEFAULT_MAX_FEEDRATE. DEFAULT_MAX_FEEDRATE will still "over rule" any attempt in MANUAL_FEEDRATE to go faster for moves requested from the LCD. So, set MANUAL_FEEDRATE to whatever lower speeds you want once you have your DEFAULT_MAX_FEEDRATE values figured out.

    FOLLOWUP COMMENT: It would be just as useful for people to describe attempts at settings that didn't pan out.

    FOLLOWUP COMMENT #2: The thread morphed into my attempt at better understanding each of the settings and putting together gcode snippets that could be used to demonstrate or test different values. This in turn has led to insight beyond the Marlin motion settings - stepper motor drive adjustment, limits on certain slicer settings, extruder E-steps calibration, etc. I've often added "homework" that is intended to encourage readers to walk through the math on their own, or to look at the specifics of their unique situation. I have tried to not make any of this up on my own; links to key references I found are included for those who want to rethink my interpretations of them.

    FOLLOWUP COMMENT #3: The thread focuses on Marlin parameters as they were named in firmware circa late 2014. Labels may vary with newer versions of Marlin. Tests were performed on an i3v with OEM-like M5 threaded rods on the z-axis and belt pulleys on x and y. Extruder tests were performed with a Greg's Wade extruder and hexagon hot end. The concepts discussed here have a generic applicability, as would the gcode snippets provided for various demonstrations and tests. Only specific results on settings would expect to change for different printer models or extruder configurations.

    TABLE OF CONTENTS LINKS TO THE REST OF THE THREAD:
    INCREASING THE Z HOMING FEEDRATE
    GENERAL INFORMATION ABOUT THE MOTION SETTINGS
    ACHIEVABLE STEP RATES AND MOTOR ROTATION RATES
    ARRIVING AT VALUES FOR DEFAULT AXIS STEPS PER UNIT
    THEROETICALLY ACHIEVABLE FEED RATE VALUES
    CAN 42BHH48-050-24A TYPE MOTORS BE DRIVEN FASTER?
    A STAB AT CALCULATING A MAXIMUM PRINT SPEED
    TESTING XY TRAVEL MOVEMENTS WITH GCODE
    TESTING Z AXIS TRAVEL WITH GCODE
    TESTING EXTRUDER MOTOR DRIVE WITH GCODE
    UNDERSTANDING THE JERK SETTINGS
    UNDERSTANDING LINEAR ACCELERATION
    MARLIN MOVE PLANNING
    LINEAR CONCENTRIC SQUARES TEST
    PRINTBUS SETTINGS RECAP
    ESTIMATING A FEED RATE LIMIT ON EXTRUDER E-STEPS CALIBRATION
    RIPPLE INVESTIGATION - PART ONE
    RIPPLE INVESTIGATION - PART TWO
    Last edited by printbus; 12-31-2016 at 05:31 PM. Reason: clarifications

  2. #2
    Engineer-in-Training gmay3's Avatar
    Join Date
    Mar 2014
    Location
    USA
    Posts
    388
    Add gmay3 on Thingiverse
    Looking forward to see what we discover in this thread! I'll bet these settings can improve print quality and speed dramatically but have been a "no fly zone" on my LCD knob all this time.

  3. #3
    Technologist dacb's Avatar
    Join Date
    Aug 2014
    Location
    Edmonds, WA
    Posts
    139
    Quote Originally Posted by printbus View Post
    FOLLOWUP COMMENT: It's just as useful to describe attempts at settings that didn't pan out.
    I couldn't agree more. I've been using the stock settings from MakerFarm that you can find in my firmware fork. For these, I print at a layer height of .2 and print speed of 70 for PLA.

    I think it would be good for people to put in their extruder head too.

  4. #4
    Staff Engineer printbus's Avatar
    Join Date
    May 2014
    Location
    Highlands Ranch, Colorado USA
    Posts
    1,437
    Add printbus on Thingiverse
    INCREASING THE Z HOMING FEEDRATE
    One change that I made to my Marlin that seems to be holding up is to increase the HOMING_FEEDRATE for Z from the MakerFarm default of 50mm/min to 120mm/min. This was driven by a desire to decrease the amount of time waiting for Z to home, especially when I wasn't simultaneously waiting for the heat bed to warm up. At the 50mm/min default, a full-scale home on a 200mm printer takes 4 minutes, and a 300mm printer will take 6 minutes if they use the same rate. At the higher setting, full scale Z home should be 1 min 40 seconds on a 200mm printer and 2-1/2 minutes on a 300mm printer. One way to look at it is that this change simply brings the HOMING_FEEDRATE for Z up to the same value for Z in MakerFarm's DEFAULT_MAX_FEEDRATE (which is 2mm/sec, or 120mm/min).

    To come up with a new setting, I simply experimented with different values for the feedrate. Applying some finger pressure to one of the Z-rod couplers, I determined that Z-motor would start skipping pretty easily if I went above around 150mm/min. So, I simply backed off a bit and went with 120mm/min. Note that this is with the "run hot" style 9.5V motors, not the motors being provided in newer kits. I believe the stepper driver was set to the MakerFarm spec, but like I think clough42 also stated, I'm not sure the 9.5V motors ever put the stepper driver into a situation where the current limit setting comes into play since the high coil resistance of the 9.5V motors provide a lot of current limit all by themselves.

    FOLLOWUP COMMENT: Make sure testing is performed while driving the Z-axis upwards, where the weight of the x-carriage puts more load on the Z motors. Those that care to experiment will find you can drive the x-carriage lower a lot faster than you can upwards.

    There is a consideration that goes along with this setting. For each axis, the homing process consists of three movements. For Z, the first movement brings the nozzle down at the HOMING_FEEDRATE until the Z endstop switch activates. The second movement raises the nozzle back off the bed some distance at that same feed rate. The third movement involves moving the nozzle back down towards the bed to activating the endstop again, but at a slower rate (default is HOMING_FEEDRATE/2) presumably to improve the accuracy of the homing process. I ran my printer with a Z HOMING_FEEDRATE of 100mm/min and a proportionally higher rate for the third homing movement for months with no Z height issues observed. When I recently increased the setting to 120mm/min, I went into homeaxis() in marlin_main.cpp and changed the feed rate ratio for that third movement from /2 to /4 simply as a way to slow the movement down closer to what it was originally. The homing feed rate also factors into probe and sled movements for bed leveling. I can't speak to what effect the increase in homing feed rate would have on those actions. My personal opinion is that something like a leveling_feedrate should have been defined to use instead of using the homing feed rate so extensively.

    I saw no need to increase the HOMING_FEEDRATE for X or Y from the default of 100*60 mm/min. The same homeaxis() code is used on X, Y and Z, and I saw no harm in also slowing down the third homing movement for X and Y. They happen in a flash anyway on X and Y, and slowing down that third leg of movement is probably good for the result.

    EDIT: A non-ABL version of homeaxis() from marlin_main.cpp is shown here. Look for the feedrate = homing_feedrate[axis]/2 line and change it to /4 or whatever you want. I use the ABL baseline even though I don't have ABL. The same lines of code are still in the ABL version of marlin_main.cpp, but they're harder to find since the code is all chopped up by ifdefs related to ABL.

    Code:
    static void homeaxis(int axis) {
    #define HOMEAXIS_DO(LETTER) \
      ((LETTER##_MIN_PIN > -1 && LETTER##_HOME_DIR==-1) || (LETTER##_MAX_PIN > -1 && LETTER##_HOME_DIR==1))
      if (axis==X_AXIS ? HOMEAXIS_DO(X) :
          axis==Y_AXIS ? HOMEAXIS_DO(Y) :
          axis==Z_AXIS ? HOMEAXIS_DO(Z) :
          0) {
        current_position[axis] = 0;
        plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
        destination[axis] = 1.5 * max_length(axis) * home_dir(axis);
        feedrate = homing_feedrate[axis];
        plan_buffer_line(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS], feedrate/60, active_extruder);
        st_synchronize();
       
        current_position[axis] = 0;
        plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
        destination[axis] = -home_retract_mm(axis) * home_dir(axis);
        plan_buffer_line(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS], feedrate/60, active_extruder);
        st_synchronize();
       
        destination[axis] = 2*home_retract_mm(axis) * home_dir(axis);
        feedrate = homing_feedrate[axis]/2 ;   <---- EDIT HERE
        plan_buffer_line(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS], feedrate/60, active_extruder);
        st_synchronize();
       
        axis_is_at_home(axis);     
        destination[axis] = current_position[axis];
        feedrate = 0.0;
        endstops_hit_on_purpose();
      }
    }
    Last edited by printbus; 06-16-2015 at 12:36 PM.

  5. #5
    Staff Engineer printbus's Avatar
    Join Date
    May 2014
    Location
    Highlands Ranch, Colorado USA
    Posts
    1,437
    Add printbus on Thingiverse
    Some general info for those just starting to look at the motion settings...

    1. Watch the units. Assuming metric, g-code F parameters for feed rate on G1 commands are in mm/minute. Most of the Marlin settings are in mm/sec. Slicer units vary. I like the way some of the Marlin source code has the values for mm/minutes entered as, for example, 2*60. That helps one realize/remember that the setting is 2mm/sec, multiplied by 60 to come up with the value in mm/min.

    2. Watch out for EEPROM settings. ABL folks are well aware of this issue, but if you have EEPROM enabled you can run into issues seeing the effect of changes you're making in source code. That's because the old EEPROM values will be used for settings even though you've loaded new firmware into the printer's flash memory. To update the EEPROM settings after a firmware upload, you should send the printer an M502 command to load the variable space with data from the firmware build, and then an M500 to have Marlin copy those variables into EEPROM.

    3. Repetier-Host users, note the EEPROM access available through Config | Firmware EEPROM Configuration once RH is connected to the printer. This provides a way to view, edit and restore EEPROM data without having to browse through the LCD or deal with gcodes.

    4. Mapping between configuration.h motion settings, the settings under the LCD control | motion menu, and settings via gcode is as follows:
    HOMING_FEEDRATE {X,Y,Z,E} is not in the LCD menu tree. M210 in gcode but not supported in our Marlin.
    DEFAULT_MAX_FEEDRATE {X,Y,Z,E} is Vmax x, Vmax y, Vmax z, and Vmax e on LCD. M203 in gcode.
    DEFAULT_MAX_ACCELERATION {X,Y,Z,E} is Amax x, Amax y, Amax z, and Amax e on LCD. M201 in gcode.
    DEFAULT_ACCELERATION is Accel on LCD. M204 S in gcode.
    DEFAULT_RETRACT_ACCELERATION is A-retract on LCD. M204 T in gcode.
    DEFAULT_XYJERK is vxy-jerk on LCD. M205 X in gcode.
    DEFAULT_ZJERK is vz-jerk on LCD. M205 Z in gcode.
    DEFAULT_EJERK is ve-jerk on LCD. M205 E in gcode.
    DEFAULT_AXIS_STEPS_PER_UNIT is Xsteps/mm, Ysteps/mm, Zsteps/mm and Esteps/mm on LCD. M92 in gcode.

    5. Note in the above list that every constant with a DEFAULT prefix also has a gcode associated with it. The DEFAULT label simply implies that will be the value used by the printer until it is superseded from the LCD or a gcode command.

    6. There is a code limitation that kicks in when trying to use the LCD panel to edit the Amax z parameter. The code assumes the user will be selecting a number beginning with 100 and incrementing/decrementing by 100. Unfortunately, the MakerFarm default for Amax Z is 5. With the code the way it currently is, once you bring up the Amax Z screen, the value changes to 100 and you can't return it to 5. Stay out of the Amax Z menu item unless you want to adjust the value in increments of 100.

    7. There's an order of precedence to some of the settings. DEFAULT_MAX_FEEDRATE sets the upper speed limit for the printer. Faster feed rates specified in MANUAL_FEEDRATE, HOMING_FEEDRATE, or a gcode command will be limited to the setting in DEFAULT_MAX_FEEDRATE. Only a new firmware build or the LCD will allow you to set a higher feed rate.
    Last edited by printbus; 12-31-2016 at 05:27 PM.

  6. #6
    Engineer
    Join Date
    Jul 2014
    Location
    Eastern Colorado
    Posts
    536
    Quote Originally Posted by printbus View Post
    I like the way some of the code has the values for mm/minutes entered as, for example, 2*60. That helps one realize/remember that the setting is 2mm/sec, multiplied by 60 to come up with the value in mm/min.
    Huh, so that's what that was for. I'm dense.

  7. #7
    Staff Engineer printbus's Avatar
    Join Date
    May 2014
    Location
    Highlands Ranch, Colorado USA
    Posts
    1,437
    Add printbus on Thingiverse
    ACHIEVABLE STEP RATES AND MOTOR ROTATION RATES

    We can at least continue to expand the knowledge base related to the settings and see where it takes us...

    http://reprap.org/wiki/Step_rates suggests the maximum "achievable" step rate for an ATMEGA processor and RAMPS is 16,000 steps per second. No insight into how this was determined is provided. For RAMPS and its typical stepper driver boards based on the A4988 chip, a selection of full-step, 1/2-step, 1/4-step, 1/8-step, and 1/16-step microstepping can be made through three jumpers on the RAMPS board under each stepper driver board. The MakerFarm configuration, if not a fairly universal configuration, is to install all three jumpers to select the 1/16 microstepping mode.

    Standard reprap step motors move in 1.8 degree increments per full step, or 200 full steps per revolution of the shaft. At 1/16 microstepping, this is 200 * 16 or 3,200 microsteps per revolution. So, the step rate wiki suggests an achievable motor shaft rotation rate of 16,000 steps per second / 3,200 steps per revolution, or 5 revs per second.

    Coming up: an explanation of the numbers in DEFAULT_STEPS_PER_UNIT, and using the achievable step rate and DEFAULT_STEPS_PER_UNIT values to imply theoretically "achievable" feed rate settings.
    Last edited by printbus; 12-21-2014 at 12:07 PM.

  8. #8
    Staff Engineer printbus's Avatar
    Join Date
    May 2014
    Location
    Highlands Ranch, Colorado USA
    Posts
    1,437
    Add printbus on Thingiverse
    ARRIVING AT VALUES FOR DEFAULT_STEPS_PER_UNIT

    The DEFAULT_STEPS_PER_UNIT in configuration.h defines the number of motor steps required to achieve 1mm of linear movement for each axis. So, the stock MakerFarm DEFAULT_AXIS_STEPS_PER_UNIT {80, 80, 4000, 841} statement says X and Y both take 80 steps per millimeter of movement in those axes. Z requires 4000 steps per millimeter of vertical movement of the x-carriage. The extruder motor requires 841 steps per millimeter of raw filament drawn into the hot end.

    All four numbers in DEFAULT_STEPS_PER_UNIT are basically the means to factor the mechanical gearing involved with the respective motor. On the stock MakerFarm i3v printers, the X and Y axes are identical with a 20-tooth pulley on the motor driving 2mm pitch GT2 belts. The Z-motors drive M5 threaded rods with a pitch of 0.8mm (linear travel or lead will be 0.8mm per rod revolution). The steps-per-unit value for the extruder motor reflects a number of things, including the number of teeth on the small gear on the motor, the large gear on the hobbed bolt, and the diameter of the channel cut into the hobbed bolt, and maybe to some extent, how deeply the hobbed bolt cuts into the filament.

    THE X and Y AXIS
    For X and Y, the math is steps per mm = (motor full steps per rev * driver microstepping) / (belt pitch * pulley teeth). The motors are 200 full steps per revolution, we're using 16x microstepping, belt pitch is 2mm, and there's 20 teeth on the pulleys. So, steps per mm = (200 * 16) / (2 * 20), or 80 steps per mm. There you go. Note that the 80 steps per mm provides an XY position resolution of ( 1 mm / 80 steps per mm ) or 0.0125mm. This is the best Marlin will be able to do in positioning the nozzle in the X and Y axes.

    Were you expecting to see the pulley circumference equation 2*pi*r factored into things here? What's really important is how much belt moves for a turn of the pulley. The number of cogs on the pulley multiplied by the distance between teeth on the belt is essentially already the circumference of the pulley after adding the thickness of the belt to it.

    THE Z AXIS
    Here the MakerFarm printers have M5 threaded rods instead of the pulleys and belts. The steps per mm of vertical travel = (motor full steps per rev * driver microstepping) / (thread pitch). Thread pitch for M5 rods is 0.8mm, so the steps per mm = (200 * 16) / 0.8, or 4000. The 4000 steps per mm provides a Z axis height resolution of ( 1 mm / 4000 steps per mm ) or 0.00025 mm. Seriously. Adjusting for layer height in 0.1mm increments certainly won't be a challenge. Some of that precision, however, comes into play for things like bed leveling, printing with a spiral perimeter, and z-hop.

    THE EXTRUDER
    A similar equation could be provided for the extruder, but I'm not going to bother. This is the one term that is best optimized by a calibration process, so understanding the math behind it is of marginal benefit.

    REFERENCES AND FOOTNOTES
    Joseph Prusa offers http://prusaprinters.org/calculator/ as a place where you can pick or enter the parameters and the result is calculated for you. Use the 'Steps per millimeter - belt driven systems' section for the X and Y axes, 'Steps per millimeter - leadscrew driven systems' for the Z axis.

    Triffid Hunter walks through the gear ratio math in http://reprap.org/wiki/Triffid_Hunte...Guide#XY_steps

    Next up - combining the information so far on a conceptual value for maximum feed rates.
    Last edited by printbus; 12-15-2014 at 04:02 PM.

  9. #9
    Staff Engineer printbus's Avatar
    Join Date
    May 2014
    Location
    Highlands Ranch, Colorado USA
    Posts
    1,437
    Add printbus on Thingiverse
    THEORETICALLY ACHIEVABLE FEEDRATE VALUES

    We can apply the DEFAULT_STEPS_PER_UNIT values and the rep rap wiki achievable motor step rate of 16,000 steps per second to come up with a notion of achievable feedrates. The achievable feed rate = ( achievable step rate ) / (steps per mm).

    THE X AND Y AXIS
    We've already affirmed the value of 80 steps per mm for the X and Y axis. The achievable feed rate = ( 16,000 steps per second ) / ( 80 steps per mm), or 200 mm per second. The stock firmware from MakerFarm sets the DEFAULT_MAX_FEEDRATE for X and Y to 250 mm/sec. This suggests the 16,000 steps per second value is an understatement, that the MakerFarm value is eating into margin possibly factored into the achievable step rate, or that the MakerFarm value of 250 mm/sec is a bit excessive.

    I've briefly ran my printer as high as 350 mm per second feed rate on X and Y, but the motors get more and more susceptible to skipping steps as the rate goes up.

    THE Z AXIS
    Using 4000 steps per mm for the Z axis, the achievable feed rate = ( 16,000 steps per second ) / ( 4000 steps per mm), or 4 mm per second. Stock MakerFarm firmware has DEFAULT_MAX_FEEDRATE set to 2 mm per second for Z.

    Some other limitation evidently comes into play here. I've briefly ran my Z axis at values between 2 and 5 mm per second, but the best I thought I could do reliably without motor skipping was about 2.2 mm/sec. So, unlike the X and Y axes, Z can't obtain the achievable feed rate. These tests weren't very scientific though - I only tested them by applying some drag using a finger rubbing on one of the rod couplers on 2mm movements. EDIT: A later post concludes that the motors on my printer are what is likely limiting the motor rotation speed.

    THE EXTRUDER
    In calibrating the extruder value in DEFAULT_STEPS_PER_UNIT, I think everyone ends up with a value higher than 841. For simplicity, I'll use a notional value of 900 steps per mm in an example. The achievable feed rate = ( 16,000 steps per second ) / ( 900 steps per mm), or 17.8 mm per second. Stock MakerFarm firmware uses a value of 22 mm per second for Z in DEFAULT_MAX_FEEDRATE.

    I haven't figured out what to do with my experimental testing on the extruder feedrate. Extruding in free air (not printing), I started seeing the extruder and extrusion getting wonky by about 5 mm per second. For example, at slow speeds the extrusion flow stayed consistent at about my 0.4mm nozzle size. At higher speeds the extrusion jumped to being much wider at around 0.9mm measured when cold. Again, I'm still pondering this.

    I did find a source that suggested the extruder value in DEFAULT_MAX_FEEDRATE mainly comes into play in retraction. In that regard, seeing the achievable max feed rate calculate to 17 mm/sec might explain why the 30mm/sec retraction rate in the MakerFarm Slic3r configuration files has been found by some to be too high.

    CONCLUSIONS
    Without anyone jumping in to prove otherwise, the data so far suggests DEFAULT_MAX_FEEDRATE {200, 200, 2, 17} would be more appropriate than the {250, 250, 2, 22} provided by MakerFarm. The 200 mm/sec for XY and 17 for the extruder are based on the calculated achievable feed rate values using reprap suggestions. The 2 mm/sec for Z is based on the fact that testing indicates the achievable feed rate isn't possible here and that one can't get much more than that with at least some of the motors MakerFarm has used. The data here also suggests a slicer retraction speed setting of 17 mm/sec or less.

    With a baseline in hand for DEFAULT_MAX_FEEDRATE, let's take a look at MANUAL_FEEDRATE in configuration_adv.h. The MakerFarm defaults for this is MANUAL_FEEDRATE {50*60, 50*60, 4*60, 60}, with values in mm per minute. IMO, the 50 mm/sec rates for X and Y seem slow, but I find the above 200 mm/sec rates are too fast for safe use with the LCD. 100 mm/sec or 100*60 mm/min seems comfortably fast. DEFAULT_MAX_FEEDRATE limits the high end, so there's no reason to set the Z rate higher than 2 mm/sec or 2*60 mm/min. Another personal opinion, but I think the 1 mm/sec extrusion rate is slow, but that the 17 mm/sec value from DEFAULT_MAX_FEEDRATE is faster than we need for extrusions requested from the LCD. 5 mm/sec or 5*60 mm/min fits better. So, MANUAL_FEEDRATE {100*60, 100*60, 2*60, 5*60} is suggested.

    FOLLOWUP COMMENT: We later discuss how the sustainable extruder feed rate, when extruding, is driven by the size of the filament. The 5*60 value suggested here is at or near the upper limit for 1.75 mm filament. For the same extruded volume, the feed rate using 3mm filament would be slower. A value of 1.5*60 to 1.7*60 would likely be a better fit for 3mm filament. The 4*60 rate in the MakerFarm defaults is not a rate that can be sustained for a long time using 3mm filament.

    With at least Cura or Cura Engine, we can leverage these settings into updates there. Travel feed rate, Z axis feed rate, and manual extrusion rate can be set to match these, adjusting for seconds vs minutes in the units as appropriate. For lack of better guidance, I also set manual retraction rate to the manual extrusion rate.
    Last edited by printbus; 06-16-2015 at 12:34 PM.

  10. #10
    Staff Engineer printbus's Avatar
    Join Date
    May 2014
    Location
    Highlands Ranch, Colorado USA
    Posts
    1,437
    Add printbus on Thingiverse
    SUGGESTED HOMEWORK AND INDEPENDENT RESEARCH

    While we wait for the conjuring of improved settings that have been validated from someone...

    Consider playing around with the Z axis details in the Prusa leadscrew calculator. Note how using a metric pitch threaded rod to obtain metric linear movement typically always involves an integer number of steps. Switch to using Imperial threads in the calculator and see about all you can do is get close. Use Prusa's Optimum Layer Height calculator to grasp the pain those with Imperial rods have in trying to obtain nice, even metric layer heights. After playing with the calculator, you'll likely never buy a printer with Imperial threaded rods.

    What would happen to the DEFAULT_STEPS_PER_UNIT for the Z axis if the M5 Z rods were replaced with M6 or M8?

    Increasing the difficulty now since at least the Prusa calculator doesn't have a pull-down for it, how would the DEFAULT_STEPS_PER_UNIT change if the Z rods were replaced with 8MM ACME leadscrews that have say a 4mm travel per turn (often listed as Tr8*4) or the harder to find 2 mm travel per turn (Tr8*2)?

    The value of 4000 steps per mm for the Z axis in DEFAULT_STEPS_PER_UNIT seems to be a large number of steps providing an excessively small position resolution. Using higher pitch M8 or 8MM ACME leadscrews would reduce the number of steps required to obtain the same linear movement. Ignoring any other limitations like available motor torque, reducing the number of steps required per mm movement would also increase the achievable feed rate. What kind of achievable feed rate on the Z axis might be possible with the M8 or 8MM ACME with 4mm per turn travel used instead?

    Now repeat as much of this as required to assess what would happen to the Z axis achievable feed rate if you reduced the microstepping on the Z-axis motor to something other than 1/16.

    What would happen if the 20 tooth pulleys on the X and Y motors were replaced with ones that have 16 teeth?

    FOLLOWUP COMMENT: Most of these are pretty straightforward to answer. My point is to get people familiar with the mechanics involved in their printer, or at least provide a one-stop summary with the math and tools that makes it easier to do so. Also note that I'm not necessarily proposing change-out of the Z rods or motor pulleys, since doing so may reveal other issues. My plan is to leave those upgrades outside the scope of this thread.
    Last edited by printbus; 12-21-2014 at 12:16 PM.

Page 1 of 6 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •