# Specific 3D Printers, Scanners, & Hardware > RepRap Format Printer Forum > MakerFarm Forum >  Marlin Motion Related Configuration.h Settings for MakerFarm i3v

## printbus

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

----------


## gmay3

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.

----------


## dacb

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

----------


## printbus

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



```
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();
  }
}
```

----------


## printbus

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.

----------


## AbuMaia

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

----------


## printbus

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

----------


## printbus

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

----------


## printbus

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

----------


## printbus

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

----------


## TechMasterJoe

> *SUGGESTED HOMEWORK AND INDEPENDENT RESEARCH*
> 
> While we wait for the conjuring of miracle answers...
> 
> 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.  Imagine now the pain those with Imperial rods have in using nice, even metric layer heights.  After playing with the calculator, you'll likely never buy a printer with Imperial threaded rods. 
> 
> What might happen to the DEFAULT_STEPS_PER_UNIT for the Z axis if the Z rods were replaced with 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 a 2.5mm pitch?  
> ...


if your ok with some more noise you can remove a jumper from Z and speed it up 2X by switching to 2000 steps per mm or 1/8th micro i have done this to the printer we have at school it has a massive .8 nozzle and uses 3mm abs all day so i switched a few things i changed the pulleys to 16 tooth and dropped x and y to 1/8 micro i can't tell at all in the prints But for the speed boost it has net me it was worth my time. i was at the limits at what that POS can do right around 140mm/s infill before it start skipping now i print all day with infill at 210mm/s bridges at 60mm/s rest at 100mm/s first layer at 40mm/s using hair spray

----------


## printbus

*CAN 42BHH48-050-24A TYPE MOTORS BE DRIVEN FASTER ?*

I went into this knowing I could reliably spin the Z motors up to a linear Z axis movement of about 2.2 mm/sec.  When I was trying a bunch of different settings on my printer, I found I couldn't really turn the Z motors much faster when I had RAMPS and Marlin configured for 1/4 microstepping (for 1000 steps per mm) instead of the normal 1/16 microstepping.  Testing with a 10mm travel, the motors would start accelerating up fine, but just give up and sit until some slower speed when Marlin was decelerating back to a stop.  I could reliably maybe get to 2.5 revs per second, from the 2.2 I already knew I could do. I was expecting more available torque as microstepping was reduced, and with it maybe a higher rotation rate. One possibility is that I was losing torque to resonance, which sounds like a common issue. 

 Another possibility is the "run hot" 42BHH48-050-24A type motors I have on my Z-axis. In thread MakerFarm Prusa i3 and i3v 66 oz. in. Stepper Motor Specifications, clough42 says these earlier 9.5V/0.5A motors have 20 to 30 ohms resistance and 30+ mH of inductance per coil. It seems to me that the comparatively high inductance on this motor type could be a real limiting factor in driving the motor faster.

I had previously replaced that same type motor on my extruder with a KYSAN 1124090 (4.2v, 1.5a, 2.8 ohm resistance, 4.8 mH inductance, 75 oz-in torque).  As another experiment, I connected the Kysan motor to the Z stepper driver still configured for 1/4 stepping and removed the filament from the extruder.  Testing with travel distances between 10 and 50 mm, I found I could reliably spin the extruder motor and gearing with hobbed bolt up to the rate necessary to get what would be 8 mm per second travel rate on the Z axis (10 revs per second). Marlin acceleration factors were left as they were. 

True, the Kysan is a higher torque motor, and it's fair to assume that the mechanical drag from the extruder gearing is different than the z-rods (but to which favor I'm not sure). This test still suggested to me that as far as trying to drive the 42BHH48-050-24A motors any faster, well, they likely aren't suitable for it. 

FOLLOWUP COMMENT: I did eventually replace all of my remaining 42BHH48-050-24A motors with Kysan 1124090 motors.  With the Z stepper driver still configured for 1/4 microstepping, the best I could reliably get out of the Kysan Z motors was somewhere around 3.5 mm/sec.  With the Z stepper driver reconfigured for 1/16 microstepping, I couldn't get much more than the 2mm/sec rate.   The difference makes sense since the amount of torque available from a stepper motor goes down with increased microstepping.  

NOTE: Starting about with shipments for the 10-inch i3v, MakerFarm is no longer believed to be using the 42BHH48-050-24A motors.  The limitation observed here may not be applicable to the newer motors.

----------


## printbus

*ACME LEADSCREW CLARIFICATIONS*

Some of my earlier information about leadscrews was misleading since I didn't know enough about them. I've corrected the earlier post(s), but this should help others from being similarly confused when starting to look at lead screws as a possible upgrade.  

My misunderstanding was in assuming that an 8mm diameter leadscrew with a 2mm pitch would provide 2mm linear travel for each rotation of the rod. Turns out that's not likely.  

A standard screw or threaded rod has a single thread.  In that case, the linear travel possible per turn, or lead, is the same as the distance between ridges of the thread, or pitch.  On an ACME type lead screw, there are usually multiple threads essentially operating in parallel.  A "four start" has four threads machined into the rod.  A "two start" has two.  Pitch is still the distance between ridges on the thread, but it's now the distance between adjacent threads, not the same one. Here, the linear travel per turn, or lead, is the pitch multiplied by the number of thread starts.  Although the thread pitch is 2mm for both, a four start 8mm diameter leadscrew will provide a lead of 8mm per turn, and a two start leadscrew will provide a lead of 4mm per turn.  The amount of torque required goes up with the lead value. I've read about people having problems driving 4-start leadscrews on the Z-axis due to inadequate torque from their stepper motors.  

REFERENCES: 

I found this to be helpful - http://www.protoparadigm.com/news-up...n-3d-printers/, including links to other info.

Info on decoding the Tr8*8(P2) kind of label some suppliers use on their lead screw is available at - http://www.shapeoko.com/forum/viewto...=1554&start=10

----------


## printbus

*A STAB AT CALCULATING A MAXIMUM PRINT SPEED*

So far, we've put a lot of faith in the achievable step rate of 16 kHz stated in http://reprap.org/wiki/Step_rates.  But configuration_adv.h has a MAX_STEP_FREQUENCY parameter defined to 40000. By label alone, it sounds like we should use 40 kHz instead of 16 kHz in our calculations, right?

MAX_STEP_FREQUENCY is used in setting up a timer value in stepper.cpp.  Reading the code doesn't do well at suggesting what's going on here.   I found M2 vs. Marlin: Speed Calculations and a comment in Makergear M2: Z Axis Numbers helpful.  Up to a step rate of 10 kHz, Marlin will create stepper interrupts at the rate required.  Over a 10 kHz step rate, Marlin keeps the timer interval at 10 kHz but starts combining two steps into each interrupt.  Over a 20 kHz step rate, Marlin starts combining four steps into each interrupt interval.  The references suggest combining steps in each interrupt can lead to jitter since the interval between steps won't be consistent.  

So, one thought is to keep the step rate below 10 kHz to stay away from this jitter.  Since we only care about this when we're printing, we don't need to worry about the reduced limit for Z-axis moves (well, maybe if you're printing spiral or with ABL but then the Z axis moves are slow).  If the DEFAULT_MAX_FEEDRATE value for the extruder really only comes into play for retractions, we don't need to worry about the reduced limit there either.  Nor with non-printing X-Y moves.  So, we can tentatively leave DEFAULT_MAX_FEEDRATE alone and deal with the 10 kHz step rate as a limit on maximum print speed we use in the slicer instead. 

Revisiting our feed rate equation for X and Y, the max print speed would = ( steps per second / steps per mm).  Steps per mm was previously baselined to 80 for X and Y.  Plugging in the numbers we get max print speed = ( 10,000 / 80 ) or 125 mm/second. So, ignoring an obvious question on whether the hot end can keep up and whether we need to adjust for stepping that has to also occur on the extruder motor while printing, we should be able to print perhaps up to 125 mm/sec before we risk picking up the jitter effects of handling motor steps in groups of two or four instead of individually.  Why not add some margin and shoot for a max print speed of 100 mm/sec?  

It's at least a place to start.

----------


## gmay3

Just checking in to say that these posts have been really interesting reads and keep em coming!  :Smile:

----------


## printbus

> Just checking in to say that these posts have been really interesting reads and keep em coming!


Thanks. I was starting to wonder.  I hope to eventually provide similar background for the acceleration and jerk settings, but they're going to take some time.

EDIT:  It'll take more of my time, but I'll likely try to work through acceleration and jerk testing with the existing CW motors, and then recheck things after I retrofit Kysans in for the rest of the motors.  I figure it'd be interesting to see where they make a difference.

----------


## printbus

*TESTING XY TRAVEL MOVEMENTS WITH GCODE*

Some simple gcode files were useful in checking out the mechanics of my i3v.  Here are sets of gcode for use with the X and Y axes, with Z and the extruder to follow later. Copy the gcode into text files and "print" them either via the SD card or your host software. You don't need to heat up the hot end to run these.  I used the Repetier Host gcode editor to adjust values between prints. 



```
; gcode for testing the X axis
; be sure to manually position Y and Z first to clear bed clips etc.
G28 X  ; home X to initialize it
M201 X500 ; this will override the DEFAULT_MAX_ACCELERATION for X
G0 F12000  ; set travel rate to be used in mm per minute
G0 X180    ; move to X = 180 mm
G0 X20     ; move to X = 20 mm
G0 X180
G0 X20
G0 X180
G0 X20
G0 X180
G0 X20
```

After homing the X axis, the X carriage will move back and forth between X=20 to X=180 a handful of times, at the feed rate specified by the G0 F command, using the max acceleration value from the M201 command.  In this example, the travel rate is set to the 200 mm/sec (or 12,000 mm/minute) DEFAULT_MAX_FEEDRATE value derived in an earlier post.  You can edit the 180 to a larger value if you have the 10 inch or 12 inch printer, and you could repeat the G0 X180 and G0 X20 lines as desired if you want more passes.  

You can change the M201 command value to get a feeling for the effect different max acceleration values have. Go lower and you'll be able to grasp how a low acceleration value can keep the X carriage from getting very fast - it will eat up too much of the available distance accelerating and then decelerating.  You can play around with higher (faster acceleration) values, but above some point you won't see any difference - perhaps because the DEFAULT_ACCELERATION or the DEFAULT_XYJERK factors are coming into play. We'll get into those settings later.  

You can use this test to determine whether you have motor skipping issues at the DEFAULT_MAX_FEEDRATE value you've settled on for X.  If you don't know how to tell if your motor is skipping keep cranking the value up. You'll figure it out.  

I've noticed the X belt occasionally resonating over by the X-motor on some prints. Running this gcode indicated the belt resonated reliably at the 12000 mm/minute max feed rate rate.  By experimenting with the value in the G0 F command, I determined the belt resonation occurs until I drop down to about a 9500 mm/min feed rate, or what would be about 158 mm/sec for X in DEFAULT_MAX_FEEDRATE. This is above the max printing speeds we've discussed, so the belt flutter would only be occurring on travel moves.  I'm not sure the flutter on travel moves would affect print quality, so it might be a non-issue.  Yeah, I could add more adhesive Velcro loop to the belt channel of the aluminum extrusion to dampen the resonation, but I want to find a more elegant solution that doesn't risk catching on the X-carriage belt mount hardware. Until then, I'm sticking with a max feed rate of 158 mm/sec so I simply know the belt flutter won't be there. 

I've also noticed bursts of a resonation coming from the X-carriage and extruder on pretty much every print, but I've never been able to determine the source of it. Running this test, the resonation would briefly occur during the acceleration and deceleration on each leg.  More experimenting with the G0 F command revealed it happens around a feed rate of 3500 mm/min, or 58 mm/sec.  I still couldn't pin point exactly where the noise is coming from, but found I could manage it by adjusting the stepper driver trimpot for the X-motor. 

 The long travel moves were instrumental in playing with the X stepper driver trimpot, getting a feeling for what setting was too low (motor skipped a lot), and too high (leading to the resonation noise in the extruder).  I looked for a setting that gave me the ability to overcome some hand pressure on the x-carriage at the 158 mm/sec feed rate while still not making a lot of step noise.  I think I've now got a better real-world adjustment on the X-motor driver than I've had before and no voltmeter was used. FWIW, I did later measure the current limit setting at just 0.10v.  

This testing also proved, contrary to what I've said several times, that the high resistance 9.5V motors that "run hot" are in fact affected by the stepper driver current limit adjustment. 

Similar gcode for Y:


```
; gcode for testing the Y axis
; be sure to manually position X and Z first to clear bed clips etc.
G28 Y  ; home Y to initialize it
M201 Y500 ; this will override the DEFAULT_MAX_ACCELERATION for Y
G0  F12000  ; set travel rate to be used in mm per minute
G0 Y180     ; move to Y = 180 mm
G0 Y20      ; move to Y = 20 mm
G0 Y180
G0 Y20
G0 Y180
G0 Y20
G0 Y180
G0 Y20
```

The upper part of my Y-belt also resonates near the Y-motor at high travel rates, and it stops occurring at about the same 9500 mm/minute rate as well. The current limit adjustment on the Y-motor stepper driver was adjusted by feel and sound like the X-motor. I later measured the current limit adjustment for the Y-motor set to 0.12v. 

FOLLOWUP COMMENT: One thought is that the X and Y belt flutter is related to belt tension, but earlier attempts at adjusting it weren't very conclusive. Now I at least know there's a way to repeat the flutter at will and observe how things like belt tension might make a difference.  

HOMEWORK AND INDEPENDENT STUDY 
Put together some gcode that moves around the print bed in a square.  I'm envisioning a future post where we use such a test with concentric squares spaced at 10 or 20 mm so we can see cumulative effects of jerk, acceleration and feed rate settings across different sizes of square movements...

REFERENCES
The test concept leverages discussion near the end of https://github.com/ErikZalm/Marlin/issues/305#issue

----------


## AbuMaia

Dangit, you just had to post this right before I go to bed, didn't you? I'm quite interested in running this test now, and have to wait nearly 20 hours before I get a chance.

----------


## printbus

*TESTING Z AXIS TRAVEL WITH GCODE*

I'm posting Z axis testing separately since I want to make a point with it.  Here's some gcode to start with - 

PREFACE: Gcode provided below always starts by homing Z as a safe thing to do, and this adds a delay to every test while it completes.  There'd be other ways to go about this, by manually raising the X-carriage to some height and then running the test.  I went with the safe route. 



```
; gcode for testing the Z axis
G0 F120 ;prepare for a safe homing rate of 2mm/sec
M201 Z5 ;prepare for a safe homing acceleration 
G28 Z  ; home Z to initialize it
M201 Z1 ; this overrides the DEFAULT_MAX_ACCELERATION for Z
G0 F120  ; set travel rate to be used in mm per minute
G0 Z20   ; move to Z = 20 mm
G0 Z10   ; move to Z = 10 mm
G0 Z20
G0 Z10
```

This starts by homing the Z axis with a known safe Z axis feed rate and the MakerFarm default for the Z term in DEFAULT_MAX_ACCELERATION.  After homing, the X-carriage is raised to 20mm, using a real slow acceleration value.  The X-carriage is then moved between 20mm and 10mm heights a few times.  

Prior experimenting with various homing feedrates had indicated I could get resonations caused by certain Z travel rates, just like I had experienced on the X axis. This gcode starts with the slow acceleration rate of 1 mm/sec per second in order to listen for them.  Sure enough, adjustment of the Z motor stepper driver while the carriage was moving up and down eliminated the resonation sound here too.  I later measured the current limit adjustment on the Z stepper driver set to 0.125v.  

The G0 F120 feed rate is as fast as we can go with firmware built to a DEFAULT_MAX_FEEDRATE of 2 mm/sec for Z.  If you want to test faster than that, you have to either upload revised firmware or change Vmax Z from the LCD Control | Motion menu.  The gcode starts with homing performed at a proven speed so that any issues you have later with motor skips won't occur in a subsequent Z home.  It's important to understand that settings loaded into the printer by one gcode file will remain in effect until changed by another, or changed by reset, etc. 

Now it's time to fiddle with acceleration.  With the gcode as provided, we see how the Z axis slowly accelerates and decelerates for our 10mm travels.  Observe the MakerFarm default for Z acceleration of 5 mm/sec per second.  Go higher. Try 10. 50. 100. 500.  Do you observe any negative effects of a high acceleration setting? 

 Results with long-distance travels on Z are of marginal value since real prints won't involve those kinds of moves.  Here's some different gcode - 



```
; gcode for testing rapid back and forth movements on the Z axis
G0 F120 ;prepare for a safe homing rate of 2mm/sec
M201 Z5 ;prepare for a safe homing acceleration 
G28 Z  ; home Z to initialize it
M201 Z5 ; this overrides the DEFAULT_MAX_ACCELERATION for Z
G0 F120  ; set travel rate to be used in mm per minute
G0 Z20   ; move to Z = 20 mm
G0 Z19.8   ; move to Z = 19.8 mm
G0 Z20
G0 Z19.8
G0 Z20
G0 Z19.8
G0 Z20
G0 Z19.8
```

This performs a Z home and raises the carriage to 20 mm as before. Then the carriage is rapidly moved up and down 0.2mm, the same distance for a typical layer height shift.  The gcode sets the acceleration to the MakerFarm default of 5 mm/sec per second.  Note how a 0.2mm change in height is 1/4-turn on the Z rods. This makes sense since the M5 rods have a full-turn pitch of 0.8mm, so 0.2mm in height would be one fourth of that.  Now try higher values for the acceleration term.  It's hard to tell if the motor really finishes the quarter turn with higher acceleration rates like 100 or 500 mm/sec per second.  Maybe those values are fine, but 50 mm/sec per second definitely looks promising, even at this fast zig-zag height adjustment.  

Why would this be important?  After all, a print only involves a certain number of layer shifts and speeding them up will only save some number of seconds over the print. Well, increasing the Z acceleration term would also speed up incremental height adjustments for spiral contours and printing with auto-bed-leveling, and especially speed up prints if you're lifting Z on each retraction.  

In a subsequent post, I'm also going to be suggesting there's an advantage to having all the terms in the DEFAULT_MAX_ACCELERATION about the same. This is a key reason why I'm looking for an acceptable Z axis acceleration value higher than the MakerFarm default of 5 mm/sec per second. Our printers aren't a delta where the suspended hot end could bounce around on a fast move.  The 0.8mm pitch Z rods are going to inherently provide some limit in how fast we can try to raise the i3v X-carriage. The aluminum v-rails provide a movement with minimal slop, compared to round rods and notorious linear bearings used on common prusas.  IMO, we can accommodate some serious increase in the Z axis acceleration setting on the i3v.  

But first, I feel the need for some gcode to test the extruder with.

HOMEWORK AND INDEPENDENT STUDY
Revise the second block of gcode so that the travels continue in the same direction (20.2, 20.4, 20.6, etc.).  IDK, it's just something to do. 

Then add something like a 200 mSec delay between moves by adding a G4 P200 dwell command between each of the multiple G0 commands. This allows you to better see each of the height adjustments. Experiment with the acceleration term again. Does a value of 500 mm/sec per second seem to work OK? Keep that in mind for later.

FOLLOWUP COMMENT: Keep in mind that the mass of the x-carriage makes it harder for the Z motors to increase the Z-axis than to lower it.

----------


## TopJimmyCooks

Let me echo Gmay - I am following this with interest and look forward to doing some "homework".  I'm waiting until after I get my dual itty bitty extruder going so I can do my tests with the heavier end effector.  I will post any feedback.

----------


## misquamacus

Bravo printbus, I'm loving this thread! I will definitely run some of these tests as soon as I am able. Keep up the good work.

----------


## printbus

> Let me echo Gmay - I am following this with interest and look forward to doing some "homework".  I'm waiting until after I get my dual itty bitty extruder going so I can do my tests with the heavier end effector.  I will post any feedback.





> Bravo printbus, I'm loving this thread! I will definitely run some of these tests as soon as I am able. Keep up the good work.


Thanks.  I'm just another one of us trying to better understand their printer. I had no idea I would be digging into the details like this when I started the thread.  I guess I was hoping for someone already in the know to jump in and explain the Marlin move planning - the code seems overly esoteric, and I've found little related information on the web that seems both helpful and trustworthy.  As I've said in multiple threads, the more we share, the better off we all are in being able to selectively pick the information we feel is important.  In the end, there may be some conclusions here that are debatable, but it'll at least have been an interesting read in getting there.  This is another thread where I frequently go back and edit prior posts. Those just reading new posts as they appear may want to skim through the thread from the beginning at some point.

EDIT: esoteric: per google, "intended for or likely to be understood by only a small number of people with a specialized knowledge or interest".  Yeah, that fits.

----------


## printbus

*TESTING EXTRUDER MOTOR DRIVE WITH GCODE*

Silly me. All I wanted to do here was provide a means for accelerating and decelerating the extruder motor so I could listen for noise to tune away with the stepper driver adjustment. That worked with X, Y and Z, so why not here? As it turned out, this simple endeavor started to expose some of the intricacies of Marlin move planning. 

!! BE SURE TO REMOVE THE FILAMENT FROM YOUR EXTRUDER BEFORE RUNNING ANY OF THIS GCODE !!



```
; gcode for testing the extruder drive motor
; REMOVE FILAMENT FROM THE EXTRUDER BEFORE EXECUTING.
M302      ; allow cold extrusion
M204 T10 ; this will override DEFAULT_RETRACT_ACCELERATION
G0 F900  ; set feed rate to be used in mm per minute
G0 E25    ; spin motor for what would be 25mm feed
G0 E-25
G0 E25
G0 E-25
G0 E25
G0 E-25
```

We see a few new things in this gcode.  To prevent bad things from happening, Marlin normally won't allow the extruder motor to be driven unless the hot end is near printing temperature.  The M302 gcode command allows us to over-ride that, and drive the extruder motor with the hot end cold.  Even coming up with the M302 to use here was interesting. On first use of a new gcode, I typically search within marlin_main.cpp for the Mxxx or Gxxx label to make sure our Marlin supports that code. When I did that with M302, it suggested M302 is NOT supported.  More web search assured me it SHOULD be in the Marlin build, so I tried it, and it worked!  Huh? Well, it turns out that the person who added the M302 code didn't include the M302 label in the comments for it.  Freeware.  Anyway...

Then we see the M204 T gcode used to manipulate the acceleration and deceleration of the extruder motor.  The M201 command for over riding the DEFAULT_MAX_ACCELERATION values doesn't work here. Why? The Marlin move planning is smart enough to know we're not extruding while also moving the carriage, so this is considered by Marlin to be a "filament only" move.  Retraction and the recovery from a retraction would be the typical filament only moves, and someone decided a different acceleration setting should be possible for them. Hence the DEFAULT_RETRACT_ACCELERATION constant, and the separate gcode for manipulating it. The value of 10 mm/sec per second here is purposely slow in order to listen for vibrations and resonation as the motor ramps up and down.  Note the 'T' included with the M204 gcode. That implies the retraction acceleration. 

G0 F900 sets the feed rate to be used for the extruder. I'm currently running my printer with the E term in DEFAULT_MAX_FEEDRATE set to 15 mm/sec, or the 900 mm/minute shown in the gcode. Like with the Z motors, if you want to test at a rate faster than what you have in your firmware for DEFAULT_MAX_FEEDRATE, you need to load new firmware or set Vmax E higher with the LCD.    The remaining G0 commands repeat through what would be filament feed and very excessive retractions.  

Running the gcode, the extruder did make noise that could be tuned away with the trimpot on the extruder stepper driver.  I'll have to test this setting with filament installed later, but I was able to put a lot of hand resistance on the large extruder gear without noticing any motor skipping.  I have a Kysan motor installed here, but I later measured the stepper driver adjusted to a lowly 0.09V.

Let's get this more interesting and take out the minus signs on the retraction values - 



```
; gcode for testing the extruder drive motor
; REMOVE FILAMENT FROM THE EXTRUDER BEFORE EXECUTING.
M302      ; allow cold extrusion
M204 T10 ; this will override DEFAULT_RETRACT_ACCELERATION
G0 F900  ; set feed rate to be used in mm per minute
G0 E25    ; spin motor for what would be 25mm feed
G0 E25
G0 E25
G0 E25
G0 E25
G0 E25
```

If you run this right after running the prior gcode, the extruder motor will spin for just one movement and then quit.  I apologize for starting to turn this thread into a gcode tutorial too, but in the prior test Marlin was defaulting to assume absolute positioning. We were effectively telling Marlin to move between positions E=25mm and E=-25mm on the filament, and we left it at E=-25mm.   Along comes this gcode, and we first spin the extruder to get back to E=+25mm.  For the rest of the G0 E25 gcodes, we're already at E=+25mm, so Marlin concludes no further movement is necessary.   This we can manipulate with a G91 gcode to enable relative positioning, and each move will be made with respect to the current location -  



```
; gcode for testing the extruder drive motor
; REMOVE FILAMENT FROM THE EXTRUDER BEFORE EXECUTING.
M302      ; allow cold extrusion
M204 T10 ; this will override DEFAULT_RETRACT_ACCELERATION
G91       ; relative positioning
G0 F900  ; set feed rate to be used in mm per minute
G0 E25    ; spin motor for what would be 25mm feed
G0 E25
G0 E25
G0 E25
G0 E25
G0 E25
```

Now what happens?  You get the acceleration and deceleration of a 25mm feed, followed by one really long one. Huh?  This is where the smarts of the move planner are getting involved. It knows that the subsequent commands continue a movement in the same direction and at the same rate, so no deceleration and acceleration is required between them.  I'm not going to try to address why there still is deceleration and acceleration between the first G0 E25 and the second one.  I just assume it's a nuance of the planning algorithm. 

Note that once the printer is in relative positioning from the G91 command, it will stay that way until reset or instructed to go to absolute positioning with a G90.  For example, if you now go attempt to run one of the X or Y tests, you won't get far since the routine will try to move +180, go another +180, etc. and the printer won't let you move outside the set print area. The lesson here is that it doesn't hurt to preface all of your custom gcode files with the setup commands pertinent for it in order to ensure the routine does what you expect it to. Metric dimensions, absolute vs relative positioning, etc. 

HOMEWORK AND INDEPENDENT STUDY
Add a bit of dwell delay between the move commands by inserting something like a G4 P10 between them. Now the planner knows moves should stop and wait between each segment, so each segment accelerates and decelerates.

Experiment with different values for the retraction acceleration term.  Seems like this can be set pretty high, at least with the dry extrusions we're doing here.  Settle on a value and test it on some filament. Until educated otherwise, my plan is to set DEFAULT_RETRACT_ACCELERATION and the E term in DEFAULT_MAX_ACCELERATION to the same value. While they can be set to different values, they don't have to be. 

Play around with slower E feedrates if you want.  You could even insert commands to change the feed rate between the G0 commands and have some of the segments go fast, and others go slow. 

Think about how this kind of gcode should be helpful in initial testing of newly printed gears for a Wade's extruder. Those teeth on the small gear don't always firm up properly, do they?  

REFERENCES
Google is your friend as far as learning about gcodes. In addition to the reprap wiki, searching on a specific gcode command will often bring up links to forums where people have ran into questions or issues in using those codes. I usually find those links to be more helpful than the brief description provided in the reprap wiki.

----------


## printbus

*LET'S RECAP*

We've identified the key settings in configuration.h and configuration_adv.h pertinent to motion moves. Where applicable, we've shown the correlation between these settings, the settings on the LCD, and gcode commands available to manipulate them.We've identified a means to  increase the speed of homing for the Z axisWe've covered how the values in DEFAULT_STEPS_PER_UNIT are calculated for the X, Y, and Z axesUsing the reprap wiki guideline of 16 kHz as a step rate limit, we've defined theoretically "achievable" values for DEFAULT_MAX_FEEDRATE of {200,200,5,17}. The "run hot" type stepper motors on at least my printer limit my Z feed rate to about 2.Using a more conservative 10 kHz step rate based on firmware insight, we've suggested 100-120 mm/sec as a top end on X Y print speeds to use in our slicer, reserving the theoretically achievable feed rates for use in travel moves.We've explored some gcode that allows us to see real-world effects of settings like DEFAULT_MAX_FEEDRATE, DEFAULT_MAX_ACCELERATION, and DEFAULT_RETRACT_ACCELERATION on our hardware. In addition to validating tentative settings, the gcode routines are handy in looking for vibrations or resonations, and even adjusting the current limit setting on the stepper motor driver boards.

We've also discussed how multiple settings can affect the same thing. There is an order of precedence between them - 

The settings loaded in the printer set the high/fast limit on feed rates. There are the DEFAULT_MAX_FEEDRATE settings in a firmware build or stored in the printer's EEPROM.  Gcodes sent to the printer can only command settings lower/slower than the printer settings.Adjusting feed rate from the LCD has no such constraint.  The LCD can be used to change a feed rate setting higher/faster than the installed firmware build or the current setting in EEPROM.For settings other than feed rates, gcode commands can be used to adjust settings both lower/slower and higher/faster than the respective DEFAULT value in the firmware build or EEPROM settingHOMING_FEEDRATE can only set speeds lower/slower than DEFAULT_MAX_FEEDRATEMANUAL_FEEDRATE for use with LCD commanded moves can only set speeds lower/slower than DEFAULT_MAX_FEEDRATEDEFAULT_MAX_ACCELERATION applies to to X, Y, Z.  The E term applies only to extrusions while moving. DEFAULT_RETRACT_ACCELERATION is applied to the extruder for retraction and replenish filament-only moves.And here's the new point for this post.   Acceleration factors for X, Y, Z and E moving extrusions are limited to the lower term in either DEFAULT_MAX_ACCELERATION or DEFAULT_ACCELERATION.  DEFAULT_MAX_ACCELERATION simply allows you to manipulate each axis individually.  If DEFAULT_MAX_ACCELERATION is set high enough, you can manipulate them all lower through a single setting or gcode command using DEFAULT_ACCELERATION.  What happens in a retraction and subsequent recovery is not affected by this, since they are controlled by DEFAULT_RETRACT_ACCELERATION

The jerk settings are the motion settings we haven't addressed yet.  And then we need to see how the feed rate, acceleration, and jerk settings all tie together.    

HOMEWORK AND INDIVIDUAL STUDY

Gcode M204 Sx is the command for setting DEFAULT_ACCELERATION, where x is the acceleration value you want in mm/sec per second. Go back to some of the gcode exercises where the M201 command was used to manipulate acceleration factors for individual axes.  Add an adjacent row for the M204 Sx command, observing which takes precedence over the other based on the value given to each.

----------


## printbus

*UNDERSTANDING JERK SETTINGS*
There's a couple of ways to look at what the jerk settings do.  From a dead stop, the jerk setting defines the first move rate Marlin will factor into the move planning, and it will accelerate from that rate as required.  When already moving and about to make a change in speed or direction, the jerk setting defines the instantaneous step Marlin can make in the feed rate.  

Visualize this on a motor vehicle.  For the smoothest ride, you put the vehicle in gear and slowly let out the clutch and give it some gas to gradually accelerate from a stop.  To corner nice and smooth, you slow down to a near stop to complete the turn and then gradually accelerate back up to the speed limit.  All this takes time. If you're in a hurry, you can drop the vehicle into gear without using the clutch and the vehicle will lurch forward.  To save more time, you can screech around the corners almost to the point the vehicle goes out of control. Completing the turn, you might need to adjust the steering for a while to get the vehicle moving in a straight line again.  In a similar way, the Marlin jerk settings allow you to set where in the range you want the printer to run - slow and conservative, or fast and bouncy. 

 Let's fire up some gcode on the printer - 



```
; gcode for demonstrating XY jerk setting in X axis movements
; 
G21       ; metric dimensioning
G90       ; absolute positioning
;
M201 X500  ; restore safe & fast acceleration value for homing; mm/sec per second unit
G28 X      ; Home X to initialize the zero reference point
;
G0 F6000  ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
M201 X100  ; override DEFAULT_MAX_ACCELERATION for X with this; mm/sec per second unit
M205 X0  ; override DEFAULT_XYJERK for XY with this; mm/sec unit
G0 X180
G0 X20
G0 X180
G0 X20
G0 X180
G0 X20
G0 X180
G0 X20
```

After homing the X axis, this gcode will just move the carriage back and forth on the X-axis.  Gcodes are provided for manipulating feed rate, acceleration, and jerk settings pertinent to the X-axis.  As provided, the M205 gcode command sets the XY jerk setting to 0.  Acceleration has been set low so that we can observe any jerkiness at the movement end points (otherwise fast acceleration from the end points might mask it).  This is the slow and conservative extreme. Run this, perhaps with a finger resting on the xcarriage to feel for any jerk or snap at the movement extremes.  It's nice and smooth.  Focus on the movements in the middle, not the first and last ones where Marlin is factoring coming from/to a dead stop. It doesn't matter in this test, but that's an important consideration for later when we raise the jerk setting from zero.   

Now rerun the gcode, increasing the value on the M205 command each time.  At about M205 X30, you might start to feel a bit of a bump or tick as the carriage snaps to the opposite direction.  Get real aggressive and try M205 X100 to observe how that bump or tick gets very distinct.  If you haven't tried the value, load M205 X20.  20 mm/sec is the MakerFarm default setting for XY jerk. In the non-scientific testing we're doing here, that seems pretty appropriate.  Those that have the ability to measure vibration with their phone are certainly welcome to do so in comparing the effects of settings. Share the results.  

Now let's do the same test on the Y axis instead of X - 



```
; gcode for demonstrating XY jerk setting in the Y axis
; 
G21       ; metric dimensioning
G90       ; absolute positioning
;
M201 Y500  ; restore safe & fast acceleration value for homing; mm/sec per second unit
G28 Y      ; Home Y to initialize the zero reference point
;
G0 F6000  ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
M201 Y100  ; override DEFAULT_MAX_ACCELERATION for Y with this; mm/sec per second unit
M205 X0  ; override DEFAULT_XYJERK for XY with this; mm/sec unit
G0 Y180
G0 Y20
G0 Y180
G0 Y20
G0 Y180
G0 Y20
G0 Y180
G0 Y20
```

This starts at an XY jerk setting of 0 again.  This time rest your finger on the Y-bed as it moves.  The bounce at the endpoints can get pretty pronounced when you get to high value settings.  Note that X and Y share the same jerk setting.  You use the M205 Xx command to set it. There is no separate command for Y.  

Now we'll get more interesting and experiment with the extruder - 

!! WARNING: REMOVE THE FILAMENT FROM THE EXTRUDER BEFORE RUNNING THIS GCODE !!



```
; gcode for demonstrating extruder jerk settings
; 
G21       ; metric dimensioning
G91      ; relative positioning
M302      ; enable cold extrusion
;
G0 F900  ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
M204 T5  ; override DEFAULT_RETRACT_ACCELERATION with this; mm/sec per second unit
M205 E0  ; override DEFAULT_XYJERK for E with this; mm/sec unit
G0 E10
G0 E-10
G0 E10
G0 E-10
G0 E10
G0 E-10
G0 E10
G0 E-10
```

Like our earlier testing with the extruder, the gcode will rotate the extruder motor back and forth the equivalent of 20mm filament feed movements.  The gcode starts with the extruder jerk setting at 0, it runs smooth.  Adjust it upwards and you'll start to feel the snap at the ends of the rotation. The MakerFarm default for extruder jerk is 5 mm/sec.  IDK - I don't feel much difference between that and say 10 mm/sec.  NOTE: My printer didn't seem to like high jerk settings like 40 mm/sec; the motor buzzed like it was missing steps. I didn't repeat it to diagnose or figure out exactly what jerk setting causes problems.  

 There's another very important aspect related to jerk showing up in this test.  Go back and rerun the gcode with different jerk settings. Note the difference in gear rotation speed that is obtained.  The feed rate and acceleration settings in the gcode were purposely selected so you can see how controlling the jerk at endpoints can and does affect the max speed obtained of the overall movement.  In our test example here, accelerating and decelerating to a stop at the end points using the acceleration constraint it's given, Marlin can't let the motor spin as fast mid-movement like it can if it's allowed to jump-start the feed rate to say 20 mm/sec. We're showing this on the extruder simply because it's where I lucked into the right combination of settings to notice it, and here we don't need to shut down the movement once we're out of room.  The same concept would apply to the other axes. More importantly, we should be worried about this effect on X and Y since we're moving in those axes all the time.     

OK.  Now we know that having small jerk settings might lead to better prints but they might take longer to print.   Higher jerk settings will help get prints completed faster, but at risk of some ringing in the print corners as hardware settles from being snapped around.

There's still more to know regarding jerk settings.  Load up this gcode - 



```
; gcode for demonstrating simultaneous Y and Z jerk settings
; 
G21       ; metric dimensioning
G90       ; absolute positioning
;
M201 Y500  ; set safe & fast acceleration value for homing; mm/sec per second unit
G28      ; Home all to initialize the zero reference point for Z and Y
;
G0 F6000  ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
M201 Y100  ; override DEFAULT_MAX_ACCELERATION for XY with this; mm/sec per second unit
M204 T10   ; overrude DEFAULT_RETRACT_ACCELERATION for E with this; mm/sec per second unit
M205 X200  ; override DEFAULT_XYJERK for XY with this; mm/sec unit
M205 Z0  ; override DEFAULT_ZJERK for Z with this; mm/sec unit
G0 Y180 Z10
G0 Y20 Z8
G0 Y180 Z10
G0 Y20 Z8
```

Here I've taken the movements from the earlier Y jerk demonstration and added some Z moves that are occurring at the same time.  No, we're not going to use this to determine what Z jerk setting works.  When you run it, the bed slowly moves forward and back, and the carriage slowly moves up and down.  No snapping at endpoints.  Now - edit the M205 Z0 to M205 Z20.  Make sure you edit the M205 Z0 line.  What's going to happen?  Something on the Z-axis, right?  Well, maybe, but we now get a pronounced snap on the Y-axis movement.  Say what? 

The gcode as provided has the Z jerk term set to 0, and the Y jerk term set really, really high.  When you run it, the low jerk setting for Z dominates the move planning and the high jerk setting for Y doesn't come into play.  Welcome to Marlin move planning.  It is solving in a three-dimensional world, and constraints you apply in one axis can and will affect the performance of what's happening in other dimensions where a move is occurring at the same time.  

I admit that I don't know the ins-and-outs Marlin move planning, but this seems to suggest it may be best to use jerk settings that are consistent for all three axes.  The MakerFarm defaults are 20 mm/sec for XY, 0.4 mm/sec for Z, and 5 mm/sec for the extruder. Without knowing more about exactly how Marlin multi-axis moves, it seems we're at risk of the low value for Z affecting moves in the other axes.  We were able to demonstrate that here.  Again, without knowing more about Marlin planning code, this could be affecting not only Z-axis layer shifts, but also printing with spiral contours or ABL where Z is frequently adjusted, or especially with Z-lifts on retraction if that is enabled in the slicer.   In the demonstrations here, I couldn't see any negative effect of running with the Z and extruder jerk settings the same as XY.  So why worry about possibly constraining move planning by having them set lower?

I'm running out of demonstrations to add to the thread. But the next test is where everything we've discussed gets combined. 

HOMEWORK AND INDEPENDENT STUDY
About that snap we could see in the Y axis.  Why couldn't it be in the Z axis as it changes direction?  Ignoring the obvious fact that we feel it in the Y-bed...  Change the gcode so the Z movements keep moving in the same direction.  Marlin shouldn't be decelerating and accelerating Z anymore, right? Is the snap still there?

I didn't try this, but you could put together some g-code with just Z axis movements to experiment with Z jerk settings.  My guess is that nothing new is to learned by doing it, but...

----------


## sniffle

...ive got to go back and read this!

Probably tomorrow while im at work

----------


## printbus

*UNDERSTANDING ACCELERATION*
No demonstration or conclusions in this post. For those that need it, this provides a basic explanation of acceleration. Those that are already comfortable with it can roll their eyes and go back to what they were doing.

Assume an object with a fixed linear speed. Acceleration describes how rapidly the speed is changed.  If the speed is going up, acceleration is positive. If the speed is going down, the acceleration is negative, and is usually called deceleration.  A high acceleration leads to a rapid change in speed.  Low acceleration leads to a slower change in speed.  

For our printers, the acceleration units could be stated as something like mm/sec^2, mm per squared seconds, or mm per seconds squared. In this thread, I've been consistent at describing the Marlin acceleration units as *mm/sec per second*, since I find that to be the best way to describe them.  Speed is given in mm per second, or mm/sec.  Acceleration is an amount of speed change, in mm/sec, that will occur for every second of duration.  Or mm/sec per second.  

EXAMPLE: An object is at rest and accelerated at 10 mm/sec per second.  After one second, the object is moving 10 mm/sec.  After two seconds, the object is moving 20 mm/sec.  After three seconds, the object is moving 30 mm/sec.  And so on.  

Now consider a printer axis capable of 500 mm/sec per second acceleration and a maximum axis feed feed rate of 100 mm/sec.  The axis will accelerate rapidly from a dead stop and quickly hit the maximum feed rate of 100 mm/sec.  The speed stops increasing, and the axis continues moving at the 100 mm/sec limit.  

The post describing the Marlin jerk settings demonstrated how a low jerk setting in one axis can dominate over higher jerk settings for other axes in a three-dimensional move.  The same applies to acceleration settings.  The rate at which Marlin accelerates from a point will be affected by the lowest of the acceleration settings for the axes involved in the movement.  

As with the jerk settings, the farther apart the axis acceleration settings, the more this limitation can come into play. Again, without knowing enough about Marlin move planning to think otherwise, this suggests a premise that acceleration settings are best set to the same value or the at least the same ballpark. 

Reiterating a point mentioned on the prior recap post, Marlin has two acceleration settings in the configuration.h file.  DEFAULT_MAX_ACCELERATION has terms for specifying an acceleration for each axis.  DEFAULT_ACCELERATION has a single value.  Look at these as just two ways to control the acceleration, with separate gcodes.  The acceleration used will be the lowest value that from the two.  The MakerFarm default for DEFAULT_ACCELERATION is 500 and DEFAULT_MAX_ACCELERATION is {1000,1000,5,1000} for X,Y,Z and E.  Based on the lower values between the two, the acceleration terms used will be 500, 500, 5, and 500 mm/sec per second for X, Y, Z and E respectively.

----------


## printbus

*MARLIN MOVE PLANNING*
Marlin does the three dimensional move planning in the planner.cpp file.  I don't pretend to know enough about it to say more than I have.  There are some comments in the file, but I found them lacking. 

Probably the best summary I found regarding move planning was http://www.extrudable.me/2013/04/02/...th-of-z-speed/. I ran across this in searching for info on what the jerk settings are all about.  The article focuses on increasing the speed of the Z axis on an Ultimaker, but the author does provide a couple of paragraphs that summarize what happens in the move planning.  I can't attest to the complete accuracy of the description, but it fits the bits I was starting to grasp as I studied the move planning code. When I found that article, I stopped trying to understand the code and focused on how I could demonstrate things on my printer.

----------


## Mjolinor

If you are going to post theoretical descriptions of things then you need to differentiate between speed and velocity then make sure you use the correct one in your description.

----------


## printbus

> If you are going to post theoretical descriptions of things then you need to differentiate between speed and velocity then make sure you use the correct one in your description.


With no other input being provided,I've simply been documenting my learning experience as I explore the motion settings. It doesn't surprise me to find out that some of my words, examples and demonstrations may not be academically correct.  If there's a distinction between speed and velocity that makes a difference in understanding the motion settings and how to optimize them, you are welcome to share that knowledge.

----------


## Mjolinor

Velocity is a vector, speed is a scalar. There is no direction attached to speed so it is possible to maintain constant speed and travel in a  circle, it is not possible to maintain constant velocity and travel in a circle.

----------


## AbuMaia

It seems to me a moot point, as none of our axes travel in a circle.  :Smile:

----------


## Mjolinor

> It seems to me a moot point, as none of our axes travel in a circle.


Sorry, can't see the relevance of what your printer does when talking about technical explanations of what acceleration is, enlighten me.

My print head moves in circles or parts there of quite frequently, so frequently in fact that they included the G2 and G3 Gcodes specifically for it.

----------


## printbus

As the thread starter, I'm hoping we don't have to continue the discussion on speed vs velocity, angular acceleration, etc.  Mjolinor makes a technically valid point, but I believe the context of the comment goes beyond the current scope of the thread.  Everything being discussed in this thread has been, and at least in my foreseeable future posts, will continue to be predominantly in the context of linear movements of the printer axes.  

As Abumaia points out, an axis can only move linearly. It is the move planner that decides how to accomodate the possibly complex gcode commands as linear movements in X, Y, Z and the extruder, based on the axis constraints it has been given to work with.  I am sure it is this three dimensional planning that forces the complexity into the move planning code.  Ignoring the totality of that complexity in this thread is likely over-simplifying things, but I don't believe it is a flawed approach.  Once we have some fundamentals covered, it may very well be interesting to know more about how Marlin applies constraints for the independent axes into move planning for more complex objects. 

My plan has been to better understand the printer mechanics in a simple linear sense where I can easily visualize, demonstrate, see and feel the differences settings can make.  Based on what I learned, I then froze the printer with some new settings so I could see whether they negatively affect the printing of real objects. This is where I'm at now. I would have rather been just trying settings someone else offered, but as of yet that option hasn't been made available.  Personally, that's what I find the most frustrating about having to dig into the details.  

Under the realm of possibility that there's just a difference between the US and UK on layman context regarding the term speed, I did go back through the thread and adjust how and where I had used it. I'm hoping I got it close enough and we can just leave it at that.

----------


## printbus

*LINEAR CONCENTRIC SQUARES TEST*
This brings me to the last of the non-printing demonstration gcode I have currently thrown together. I plan to run the printer with some new settings for a while, perhaps adjusting to the need for some new settings in the slicer.  There may very well be better tests, but this was straightforward to put together from the demonstrations already prepared.  One thing I like about it is you know exactly what movements the printer should be doing, making it easier to anticipate what to watch for.  

*OVERVIEW*
The demonstration involves moving the printer axes in a path outlining a stack of concentric squares, from 180mm to 2mm width.  Between each square, the Z-axis is increased by 0.2mm to mimic a layer shift.  Three passes at the stack of squares is made.  The first pass moves the X-carriage and Y-bed at a high travel rate. The second pass is identical except the X-carriage and Y-bed are moved at printing feed rates.  The third pass continues with the printing feed rates, but adds in extruder movements mimicking printing and also retractions around the layer shift points.  Including homing and a few seconds of pause between each pass, the demonstration runs for around three minutes.  

!! REMOVE FILAMENT FROM THE EXTRUDER BEFORE RUNNING THE DEMONSTRATION GCODE !!

Two versions of the demonstration gcode are provided.  File squares_oem.gcode uses parameters from the MakerFarm distribution for the 8 and 10 inch i3v printers.  The same values might also apply for the 12-inch printer; I haven't downloaded the 12-inch firmware to compare settings. File squares_fast.gcode is identical except for changes I've made to DEFAULT_MAX_FEEDRATE, DEFAULT_MAX_ACCELERATION, DEFAULT_ACCELERATION, DEFAULT_ZJERK, and DEFAULT_EJERK.  Both files assume a 250 mm/sec travel rate, 100 mm/sec printing feed rate, Z feed rate of 2mm/sec, and retraction rate of 15 mm/sec.  Make sure your printer is configured for a DEFAULT_MAX_FEEDRATE of at least {250,250,2,15} before running the gcode, since gcode commands can't increase above what the printer is set to.   You can verify this by checking Vmax x, Vmax y, Vmax z, and Vmax e on the i3v LCD.  

The demonstration starts with a home-all, with all pertinent parameters set to what are known to be safe parameters. This way if you alter settings later in the gcode that mess up printer movements, the next pass of the gcode will restore anything needed for the homing to function properly.  After the home all, gcode commands are used to  set up certain demonstration parameters; those would be the parameters you could change for tailored rates you want to try.  In the pass including extruder movements, changes to XY travel rate, XY print speed, Z feed rate, and retraction/replenish speeds would require editing hardcoded values in gcode commands throughout that pass.  

*OBSERVATIONS
*I first ran the squares test with travel rate limited to the 160mm/sec rate determined earlier to not lead to X and Y belt flutter.   I found that to seem woefully slow for a travel rate used in printing, and quickly raised it to 200 mm/sec and ultimately to the 250mm/sec rate from the MakerFarm defaults.  The 250 mm/sec rate is pretty snappy.  Although it is high from the reprap wiki notion of achievable step rates, I have the perception that a lot of people have kept the 250 mm/sec rate and no one has reported any problem with it.  Interestingly, when I went to the 250 mm/sec travel rate, I no longer had any of the belt flutter that earlier drove me to the 160mm/sec rate.  In going back and verifying settings, I'm convinced that flutter had to be an artifact of previously overdriving the X and Y motors.  

In observing how the printer accelerated from each corner of a square, I thought it was interesting to see how the printer would get to the printing rate of 100mm/sec fairly quickly.  For the acceleration to a 250 mm/sec travel rate, however, I offer two opinions.  First, even on my 8-inch bed the printer took a lot of time and distance to accelerate up to the 250 mm/sec travel rate.  As the demonstration moves to the smaller and smaller squares, you see how the high travel rate is never achieved on many of the moves.  Second, the sound of the acceleration makes it seem like the motors are straining under load, and slow to get to speed. These are step motors and that isn't the case, but it sounds that way. 

I like the 15mm/sec extruder max feed rate being applied to retraction and replenish. It seems snappy enough. I've been using that on all of my prints for the last couple of weeks, and it seems to work fine.  

* TAILORED SETTINGS* *IN THE FAST DEMONSTRATION FILE*
I eventually settled on 750 mm/sec per second as values for X and Y in DEFAULT_MAX_ACCELERATION.  That seems to be a great help in getting X and Y moving at the travel rate quickly, at least quick enough that the full travel rate should now be applied to a significant percentage of travel moves.  At a glance, this may seem like a reduction from the values of 1000 in the MakerFarm DEFAULT_MAX_ACCELERATION, but with DEFAULT_ACCELERATION at 500, those higher settings were being clipped to 500.  To benefit from the higher settings in DEFAULT_MAX_ACCELERATION, DEFAULT_ACCELERATION was also changed from 500 to 750.  I could have just increased DEFAULT_ACCELERATION alone, but I just don't like propagating the confusion of having a setting that ultimately gets limited by another, so I set them to the same value.  

Z axis movements at the OEM settings seem slow, and have the same motor-under-load sound.  Earlier testing had determined the Z motors I have are limiting me to a Z feed rate of 2 mm/sec.  To speed up Z adjustments, I changed the Z term in DEFAULT_MAX_ACCELERATION from 5 to the 500 mm/sec per second originally used for X and Y.  I maybe wouldn't have had to go that high to get the benefit I was looking for, but I've seen no issue with the high value.   Z layer shifts are now very crisp and quick. I admit I've been rethinking the weight I've got strapped onto the Z-rods in the two aluminum shaft couplers - at some point they may be viewed as a limiting factor in Z motor acceleration.  The extruder was left at the 500 mm/sec per second value in DEFAULT_MAX_ACCELERATION and DEFAULT_RETRACT_ACCELERATION.  

Based on earlier experimenting, I increased DEFAULT_ZJERK from the 0.4 mm/sec MakerFarm default to 10mm/sec, and DEFAULT_EJERK from 5 mm/sec to 10 mm/Sec. DEFAULT_XYJERK was left at 20 mm/sec since I didn't want to increase the risk of XY corners ringing due to jerk.  

IMO, these few changes in settings leads to an i3v that both looks fast and sounds fast. Combined with adjusting the stepper drivers in real use and not by voltage reading, the printer sounds like an entirely different machine.  From the 160 mm/sec travel rate I entered the testing with, the settings in the fast file led to a time reduction of about 30 seconds in the demonstration.  The difference between the OEM settings file and the fast settings file is about 15 seconds on my printer.  That's not a scalable number that means much, but it does demonstrate the changes have led to a faster printer.   

In attempting to push test prints to a 100mm/sec print speed with these settings, I have ran into some issues, primarily with extrusion being light for short segments in solid infill layers like on the bottom or the top.  This did lead me to reduce the XY acceleration term from 1000 to 750 mm/sec per second, but I also simultaneously increased my extruder temp and put more attention on what the actual movement speeds were on perimeters and solid layers. I think I've just gotten by with sloppier settings on earlier prints when I haven't been pushing the printer (I'm typically slicing with Cura Engine and Repetier-Host, with all speeds proportionally adjusted through one integrated speed slider control). I also haven't ruled out the possibility that the test issues have been with the filament or the extruder stepper driver setting. To further assess viability of printing at 100 mm/sec, I'm likely going to have to look at the rate of filament volume the hot end can properly handle. I also need to validate the Y motor driver setting and Y axis acceleration term with more weight on the Y-bed than I've had in the few test prints completed.

FOLLOWUP COMMENT: The print issue I was having was evidently the stepper driver adjustment. I must have been skipping a few steps on the extruder motor.  I haven't seen the extrusion problem after adjusting the extruder driver upwards a bit more.  It is amazing how much quieter the printer runs with the readjusted driver settings.  It's also important to note that my "run hot" type motors also now hardly warm up at all.

----------


## printbus

*PRINTBUS SETTINGS RECAP*

SLICER -
Travel rate: 250 mm/sec or 15,000 mm/minute
Print rate: 100 mm/sec max, perimeters and solid layers adjusted to suit
Retraction: 15 mm/sec

MARLIN - 
HOMING_FEEDRATE {100*60, 100*60,2*60,0} (but I have also modified Z homing code in marlin_main.cpp)
 DEFAULT_MAX_FEEDRATE {250,250,2,15}
 DEFAULT_MAX_ACCELERATION {750,750,500,500}
 DEFAULT_ACCELERATION 750
 DEFAULT_RETRACT_ACCELERATION 500 
 DEFAULT_XYJERK 20
 DEFAULT_ZJERK  10
 DEFAULT_EJERK  10
MANUAL_FEEDRATE {100*60, 100*60, 2*60, 5*60} (in configuration_adv.h)

Print area is equipped with a print cooler capable of providing the airflow necessary to print PLA without minimum layer time restrictions on most prints.

FOLLOWUP COMMENT: It is determined later that the 5mm/sec value for E in MANUAL_FEEDRATE is about at the limit for a sustained extrusion using 1.75mm filament.  For the same amount of extruded volume, 3mm filament feeds slower.  1.5 to 1.7 mm/sec would be a more appropriate value for 3mm filament.

----------


## printbus

*ESTIMATING A FEED RATE LIMIT ON EXTRUDER E-STEPS CALIBRATION*

The background information leading to this has been puzzling.  Some people have reported inconsistent results if they run at the Pronterface default of 100 mm/min feed rate during extruder calibration, yet I've known I could do calibration at the 300 mm/min default in Repetier-Host.  But I've also realized my results also get more consistent if I back off from that.  And then there's the "wonky" extrusion I see when I try to extrude into free-air above a 5 mm/sec feed rate, which correlates to 300 mm/min.  As it turns out, all of these are likely tied to size of the filament being used and a notion of extrusion capacity for the hot ends. In other words, just how much volume of raw filament can the hot end melt and extrude?

It's not clear what if anything the software does with it, but Repetier-Host even has a setting for this - max volume per second, with a units of cubic millimeters per second.  The comment on the setting says one should be able to reach 12 mm^3/sec. I've seen 10mm^3/sec mentioned as a typical capacity in various web posts, with others encompassing a range from as low as 8 to as high as 18.  I haven't heard or found of a value specific to any hexagon hot end, what yet specific to a 0.4mm nozzle version of it like I have.  As with a lot of other things on the printer, it was enlightening to compare these numbers to the volume of filament necessary to support things like the extruder calibration.  

Let's assume a possibly optimistic goal of 12 mm^3/sec as the maximum amount of filament we can melt and extrude.  The input feed rate that correlates to this would depend on the filament diameter.   The area of a circle is pi*r^2.  The volume of a cylinder like our filament feed is simply the area * length.  For perfectly round and properly dimensioned 1.75mm diameter filament, the area of the filament end is about 2.4mm^2.  Calculating over a one second window for a volume of 12mm^3, the cylinder length of filament would be (volume)/(area), or (12 mm^3)/(2.4mm^2), or 5mm.  Hmmm. Right at the 5mm/sec point where I've noticed my free-air filament extrusion getting "wonky".  And 5mm/sec extends to the 300mm/minute threshold I've seen in the calibration extrusion. This suggests that a 5mm/sec feed rate while extruding seems to be at about the limit or slightly beyond the limit of my 1.75 mm hot end and 0.4mm nozzle.  

How about 3mm filament?  Area of the filament end is again pi*r^2, or just over 7 mm^2, about three times the area of 1.75mm filament.  The cylinder of filament to be extruded in one second for volume of 12 mm^3 would be (12 mm^3) /(7 mm^2), or about 1.7 mm.  1.7mm/sec is just about the same as 100 mm/minute, where some people have been reporting issues in the calibration.  Were they people with 3mm feeds and not 1.75? IDK - I should have paid more attention, but that's sounding pretty likely. 

Maybe as a conservative view, extruder calibration should be conducted at something like half these rates, or 50mm/min for 3mm filament and 150mm/min for 1.75 mm filament. 

 WHAT ABOUT OTHER CONSIDERATIONS ?

Should the E term in DEFAULT_MAX_FEEDRATE be changed to reflect this? I don't think so. DEFAULT_MAX_FEEDRATE should likely stay at the mechanical limit of the motor drive in support of retraction and replenish. We don't have to factor melting new filament for those movements.  It's just obvious now that we can't expect to be extruding at that rate, or at least not for very long.  

So the capacity of the hot end to melt filament will likely be a limit on printing speed. All you'd have to do is factor the volume of the extrusion (most places say to just calculate volume as extrusion width * layer thickness and ignore factoring rounding of the corners), and divide it into the hot end flow rate capacity to come up with a print speed limit.  The key to this would be in having a solid number for the flow rate capacity.  Variables I've read others mention include the nozzle size and temp, specifics of the filament (material, color), and effectiveness of the thermal junction between the aluminum block (the hot end heat reservoir) and the nozzle.  One source declared that the higher surface area to volume ratio for 1.75mm filament allows it to support a higher hot end throughput than 3mm.  I can logically expand this list to include more possible variables like the quality of the thermal connection between the cartridge heater and the aluminum block, whether or not the aluminum block is insulated, and if so, the quality of that insulation.  The approach used to cool the hot end heatsink could make a difference (air volume & direction, nature of insulation vs. airgap above the heat break, etc.).  The accuracy of the hot end thermistor... 

Results from any volume testing I did would likely be of little value to anyone else.  Thinking I had cross-threaded my hex hot end aluminum block, I replaced it with a different one that is 20mm square instead of the hexagon's standard 16mm block. This likely changed the characteristics of the heat reservoir formed by the block.  Since the block is larger, I've replaced the cartridge heater with one 20mm long; this heater seems faster (more effective) than the original one.  I used heatsink compound on the cartridge to block connection; I may have even put a small amount on the nozzle threads.  The aluminum block is insulated in two layers of kapton, with portions covered by three or four layers.  The hot end shroud has been customized to remove the bottom plate and to improve the amount of air forced over the hot end heatsink.  I almost always print with a print cooler running.  Most days I'm using 1.68mm diameter filament - shy of the 1.75mm "standard".  All of these factors will likely matter. 

Could there be a relationship between hot end flow volume capacity and acceleration and jerk settings?  Maybe, at least to a small extent.  By increasing XYZ acceleration and going with a higher jerk allowance, we're reducing opportunities for "slack time" where the hot end might otherwise be able to restore heat lost to extrusion.

Yes, smarts built into the heater temperature control loop can deal with a lot of the variables - at least up to some extent.  Regardless, I'm starting to see how there's more to pushing a printer to the limit than I realized.  

HOMEWORK AND INDEPENDENT RESEARCH

For the free-air extruder e-steps calibration, what limit on feed rate do you get if you assume the hot end can only handle 10 mm^3/sec?

As I understand it, some slicers attempt to keep extrusions to something like 0.4mm while others accommodate a width setting.  Do you know what yours is? Have you attempted to measure it on a thin-wall calibration print?  Assume a simple rectangle extrusion of width * layer height, and calculate an estimated print speed that equates to the hot end volume limit of your choice. 

A thicker layer or a wider extrusion on the first layer would lead to a lower limit on the print speed.  Come up with another print speed estimate based on what you think you're getting for an extrusion on the first layer. 

REFERENCES

http://www.extrudable.me/2013/04/18/...ty-and-limits/ - provides a good overview of the issue and demonstrates how feed volume capacity goes up with nozzle temperature. States that 8-10mm^3/sec is the limit for a 0.4mm nozzle. Note that the stated volume test results are high since tests were conducted with a 0.65mm nozzle - look at the data for an understanding of how temperatures, etc. affect volume flow rate, not as a baseline that you should strive for.  

http://forums.reprap.org/read.php?1,226728 - says 10mm^3/sec is typical

http://umforum.ultimaker.com/index.p...der-extrusion/ - sort of a followup to the extrudable me reference. One comment states 10mm^3/sec is the limit for a 0.4mm nozzle. Comment #8 touches on the 1.75mm vs 3mm aspect.

FOLLOWUP COMMENT: I've noticed the MakerFarm FAQ page describes the hexagon hot end as being capable of 200 mm/sec print speeds.  That seems high in comparison to the sense I'm getting regarding my hexagon hot end.  Unfortunately, MakerFarm doesn't elaborate on the test conditions where that print speed is possible.  If the test conditions are a 0.30 mm nozzle and a 0.10 mm layer height, 200 mm/sec could be reasonable because of the smaller extrusion volume involved.

----------


## N5QM

Do you expect that the extrusion feedrate could be increased by using a larger nozzle and/or wrapping the hot end in some insulated material minimizing the heat that is wasted?

Robert

----------


## printbus

> Do you expect that the extrusion feedrate could be increased by using a larger nozzle and/or wrapping the hot end in some insulated material minimizing the heat that is wasted?


I was sort of hoping someone else would offer their opinion...

I assume we're talking about the extrusion feed rate that can be obtained during printing.  To me, the limiting factor is the efficiency that the hot end can apply heat to and soften the filament being fed.  In that regard, insulating the hot end should help (to some extent) since as you said, less heat would be lost to free air.  As I understand it, new versions of the hex hot end come with an insulating jacket, perhaps for this reason.  Benefits might be had through anything that improves the efficiency of heat transfer from the heat cartridge to the nozzle.  The clamping style of the aluminum block on the E3D shows promise in this aspect.  One could also add a bit of heat sink compound to the heat cartridge and possibly even the nozzle threads to improve heat transfer across the mechanical connections. Minimizing voltage loss to the cartridge heater or even raising the 12V supply up a bit might also help since more power would be dissipating in the cartridge heater.  

I'd have to think about the nozzle diameter.  My initial response is that I don't know that it would make a difference. It seems like it could be deceiving - it might, but would the larger diameter simply be allowing flow at a lower temperature and material that isn't as soft?

----------


## N5QM

> I'd have to think about the nozzle diameter.  My initial response is that I don't know that it would make a difference. It seems like it could be deceiving - it might, but would the larger diameter simply be allowing flow at a lower temperature and material that isn't as soft?


Interesting thought.  I expect you are right, if the heater can't keep up with the demand then the larger nozzle may just extrude material that is not consistent over a larger print causing various other problems related to print quality.

----------


## printbus

> *PRINTBUS SETTINGS RECAP*
> 
> SLICER -
> Travel rate: 250 mm/sec or 15,000 mm/minute
> Print rate: 100 mm/sec max, perimeters and solid layers adjusted to suit
> Retraction: 15 mm/sec
> 
> MARLIN - 
> HOMING_FEEDRATE {100*60, 100*60,2*60,0} (but I have also modified Z homing code in marlin_main.cpp)
> ...


Except for one aspect, this has remained my baseline through dozens of prints, including around two dozen configuration controlled prints related to ripple testing.  The one aspect is that with replacement of the balance of original motors with Kysans, the Z feed rates have been increased to 2.5 mm/sec in HOMING_FEEDRATE, 3 mm/sec in DEFAULT_MAX_FEEDRATE, and 2.5 mm/sec in MANUAL_FEEDRATE.  I'm also operating the Z motors with 1/4 microstepping instead of the original 1/16.  

Elaborating on the 100mm/sec default print speed, I typically go for a 50mm/sec perimeter speed and a 80mm/sec solid infill speed.  

I continue to like these settings, especially paired with motor drive adjustments based on how the motors perform, not on a voltage setting.

----------


## N5QM

I am working through the stepper driver adjustments and have done them all except the extruder at this point.

My point in sharing that is to say that I am amazed at how much quieter they run when being driven properly!   :Smile:

----------


## printbus

> My point in sharing that is to say that I am amazed at how much quieter they run when being driven properly!


"Properly" might be debatable, but the difference in noise when driven "adequately" is pretty amazing, isn't it?  Between the difference in sound (now more musical than it is noisy) and the slightly increased speeds and acceleration, the printer seems so much more like a commercial/professional one would. I now look forward to printing cylinders so I can hear how they turn out.

----------


## printbus

*RIPPLE INVESTIGATION - PART ONE*
This is an extension of the discussion that started in thread so what causes this. The thread questions what causes the ringing or ripple appearance often occurring at sharp corners, as well as following dimples, lettering, or other recesses in printed objects. Part one lays a foundation for discussing the theories, test prints, and results.  Part two will get into the latter. 



So, I opted to run some test prints to investigate possible causes and improvements, with a focus on how the Marlin motion related settings can come into play.  



The information here is provided under the FWIW caveat.  There's no solid, clear-cut miracle fix proposed, so don't read on expecting one.  I'm only documenting the thoughts I've had on causes and the tests performed to prove them out.  Perhaps the results here will spur ideas for someone to pursue on their own.   

*THE TEST OBJECT*
A special test model was prepared for the testing in order to provide the mixture desired.  The 45mm sides enables a high speed to be reached mid-perimeter.  Corners are intentionally sharp 90 degree turns without any radius.  All four sides include a combination of a round dimple, a recessed thin rectangle, a through-hole, and a rectangular notch at the top edge.  Walls are 1.75mm thick.  The depth of dimples and recesses vary.  

An attempt was also made at a cylindrical test object, but the results were not conclusive and wouldn't photograph well.  Results from the cylindrical prints will not be addressed. 

The STL for the custom test object is available at http://www.thingiverse.com/thing:678295

*THE TEST PRINTER*
General details regarding the MakerFarm i3v 8-inch printer used for test prints can be found in my build thread at MakerFarm 8" i3v Prusa build by Printbus.  The X and Y belts are currently adjusted tight to the point of being "pluckable".  All hardware is tight. There's no slop in how the Y-bed rides on the Y-rails, the X-carriage carriage rides on the Z-rails, or the extruder carriage rides on the X-rails.  The printer is equipped with six Sorbothane Duro-70 feet, and rests on 3/4-inch plywood.  Wood 1/2-inch reinforcement plates have been added to the front and rear frame braces that support the ends of the Y-rails.  Stepper motor drivers are adjusted for suitable operation of the motors, not to a particular current limit voltage setting.

The extruder is equipped with a 1.75mm hexagon hot end with a 0.40mm nozzle. The hexagon hot end is mounted snug in the extruder/carriage assembly. The hot end is snug in the extruder/carriage assembly; there is no slop or play in the nozzle.  

*BASELINE SETTINGS*
MakerFarm black 1.75mm PLA purchased several months ago was used at the start of the test; I have considered this to be my premium filament because of resulting print quality.  Unfortunately, I ran out of that filament after I ended up printing more tests than I anticipated. The second roll was a newer purchase of MakerFarm black 1.70 PLA that doesn't print as nicely. Black filament was used in order to facilitate photographing print artifacts. 

Simplify3D v2.2.1 was used for all slicing related to these tests.  The following scroll box contains details and notes regarding the "baseline" Marlin and Simplify3D settings for the testing.  Many of these settings leverage values determined earlier in this thread.  Note that the box is simply commented text. It is not an INI or other settings file that can be downloaded and used as-is. The settings are discussed in the sequence that they appear in the Simplify3D user interface.  The settings are not intended to define the "perfect" settings for Simplify3D. They *only* define a standardized baseline configuration referenced in the print tests.  

Printing of these tests followed experimenting with Simplify3D and a single-wall calibration print. Unfortunately, the setting of a manual extrusion width of 0.39mm was inadvertently also applied to initial ripple test prints.  For consistency, this inadvertent setting was left intact through all test prints.



```
Ripple Test Print configuration summary
21 Jan 2015

 *** MARLIN DETAILS  ***
dacb fork for MakerFarm as of Sept 28 2014; personalized motion related changes:
HOMING_FEEDRATE {100*60, 100*60, 2.5*60, 0}
marlin_main.cpp homeaxis() feedrate in 3rd phase of homing reduced from /2 to /4 to negate faster HOMING_FEEDRATE
DEFAULT_AXIS_STEPS_PER_UNIT   {80, 80, 1000, 900}  (Z motor driver configured for 1/4 microstepping)
DEFAULT_MAX_FEEDRATE {250, 250, 3, 15} (3 on Z works with Kysan motors and 1/4 microstepping)
DEFAULT_MAX_ACCELERATION {750,750,500,500} 
DEFAULT_ACCELERATION 750 
DEFAULT_ZJERK 10
DEFAULT_EJERK 10 
MANUAL_FEEDRATE {100, 100, 2.5, 5} 

*** Simplify3D v2.2.1 Process Settings - Extruder
Nozzle diameter: 0.40mm
Extrusion multiplier: 1.00 
Extrusion width: Manually set to 0.39mm (see post) 
Retraction box: checked
Retraction distance: 1.80mm 
Extra restart distance: 0mm
Retraction vertical lift: 0mm 
Retraction speed: 15mm/sec (to match 15mm/sec setting in Marlin DEFAULT_MAX_FEEDRATE)
Coast at end: checked and set to 1.6mm
Wipe at end: unchecked and set to 5mm 

*** Simplify3D v2.2.1 Process Settings - Layer
Primary layer height: 0.20mm
Top solid layers: 3
Bottom solid layers: 3
Outline/perimeter shells: 2
Outline direction: Outside-in 
Print islands sequentially: unchecked 
Corkscrew printing mode: unchecked 
First layer height: 90%
First layer width: 125%
First layer speed: 50%
Start points: use random start points for all perimeters

*** Simplify3D v2.2.1 Process Settings - Additions
Include skirt brim: checked 
Skirt layers: 1
Skirt offset: 4mm
Skirt outlines: 3 
Include raft: unchecked 

*** Simplify3D v2.2.1 Process Settings - Infill
External fill pattern: rectilinear
Interior fill percentage: 20% 
Outline overlap: 15% 
Infill extrusion width: 100% 
Minimum infill length: 5mm 
Print sparse infill every 1 layer
Include solid diaphragm: unchecked
Random infill placement: unchecked 
Infill angles: 45, -45 degrees

*** Simplify3D v2.2.1 Process Settings - Support
Generate support material: unchecked 
Support extruder: Primary 
Support infill percentage: 30% 
Extra inflation distance: 0 
Dense support layers: 0 
Dense infill percentage: 70% 
Print support every 1 layer 
Horizontal offset from part: 0.50mm 
Upper vertical separation layers: 1 
Lower vertical separation layers: 1 

*** Simplify3D v2.2.1 Process Settings - Temperature
Extruder temperature identifier: T0
Extruder temperature controller type: Extruder
Extruder relay temperature between each: (neither layer or loop selected)
Extruder wait for temperature controller to stabilize: checked
Extruder layer 1 temperature: 220 degrees 
Heated bed temperature identifier: T2
Heated bed temperature controller type: heated build platform
Heated bed relay temperature between each: (neither layer or loop selected)
Heated bed wait for temperature controller to stabilize: checked
Heated bed layer 1 temperature: 55 

*** Simplify3D v2.2.1 Process Settings - Cooling
Layer 1 fan speed: 0
Blip fan to full power when increasing from idle: unchecked 
Adjust print speed for layers below set duration: unchecked 
Increase fan speed for layers below set duration: unchecked 
Bridging fan speed override: unchecked 

*** Simplify3D v2.2.1 Process Settings - G-code
Option for 5D firmware: checked
Option for relative extrusion distances: unchecked
Option to allow zeroing of extrusion distances: checked
Option to use independent extruder axes: unchecked
Option to include M101/M102/M103 commands: unchecked
Option for firmware supporting sticky parameters: checked
G-Code axis offsets all set to 0
Update machine definition using settings: checked
Machine type: Cartesian
Build volume: 200mm x 200mm x 200mm (printer dependent)
Origin offset: 0, 0, 0
Homing direction: all set to min
Flip build table axis: Y checked

*** Simplify3D v2.2.1 Process Settings - Other
Default printing speed: 100 mm/sec (6000mm/min)
Outline underspeed: 50%
Solid fill underspeed: 80% 
Support structure underspeed: 80% 
X/Y axis movement speed: 250 mm/sec (to match setting in DEFAULT_MAX_FEEDRATE)
Z axis movement speed: 2.5 mm/sec (to match setting in DEFAULT_MAX_FEEDRATE)
Filament diameter: 1.68mm 
Bridging unsupported area threshold: 50 sq mm 
Bridging extrusion multiplier: 100% 
Bridging speed multiplier: 100% 

*** Simplify3D v2.2.1 Process Settings - Advanced
Start printing at set height: unchecked
Stop printing at set height: unchecked
Non-manifold segments: heal
Merge all outlines into solid model: unchecked
Thin wall behavior: Allow gap fill when necessary
Allowed perimeter overlap: 10% 
Only retract when crossing open spaces: checked 
Force retraction between layers: checked 
Minimum travel for retraction: 2mm 
Extruder ooze rate: unchecked
Only wipe extruder for outer-most perimeters: checked 
Tool change retraction: settings ignored since I only have one extruder
```

----------


## printbus

*RIPPLE INVESTIGATION - PART TWO
*Disclaimer: The information provided is for the purpose of sharing ideas on what can cause the ripple effect and how it can be prevented and masked. There's a reasonable possibility that there is more than cause of a ripple artifact in prints.  Results obtained on these test prints may or may not be reproducible in other print objects or on other printers. 

*THE PHOTOGRAPHS*
Those that have taken a detail look at ripple on their prints understand how the appearance of the ripple depends greatly on lighting and viewing angles.  To provide a reasonable consistency between photographs, test objects were photographed on a fixture with markings for object orientation, the lighting was from a mounted reflector lamp, the camera was on a tripod, and no camera flash was used.  The standardized approach to the photos may not show the worst of the effect on each print - just a consistent view of it.  

Due to board posting limitations, result photographs are not embedded in this thread.   Photograph file names are based on the test print number.  Links to individual photographs are provided where appropriate.

*TEST PRINTS*
(no photo)  SETTINGS: Initial attempt at a baseline print. OBSERVATIONS: Artifacts from Simplify3D wipe setting complicating print finish. Print rejected; wipe setting disabled on all subsequent ripple test prints.ripple_02:   SETTINGS: Baseline print.  OBSERVATIONS: Ripple present on the trailing edge of all corners, dimples, and recesses on all four sides of the test print.  "Trailing edge" is defined as the direction the nozzle took in leaving the corner, dimple, or recess.ripple_03:  SETTINGS: Per baseline except Marlin XY_jerk decreased from 20 to 2.  OBSERVATIONS: Some reduction in ripple on surfaces in the X orientation.  Minor reduction in ripple on surfaces in the Y orientation. Some increased ballooning on edges, likely due to additional nozzle soak time at the minimal speeds enforced by the low jerk settings.ripple_04:  SETTINGS: Per baseline except Marlin overall acceleration reduced from 750 to 200.  OBSERBATIONS:  While the effect of the ripple appears to be reduced, the lower acceleration appears to "compress" the width of the ripple, not eliminate it. This would imply that the frequency of the ripple is independent of the print speed.(rejected print due to possibility Marlin had reset before the print started) ripple_06:  SETTINGS: Per baseline except E jerk setting reduced from 10 to 1 mm/sec.  With no change noted, E acceleration was also reduced from 500 to 100 mm/sec per second partway through the print.  OBSERVATIONS: No effect on ripple noted.ripple_07:  SETTINGS: Per baseline except perimeter print speed increased from 50mm/sec to 75mm/sec.  First print on new filament roll.  OBSERVATIONS: Marked reduction in ripple appearance, likely from the ripple being stretched due to the higher print speeds.ripple_08:  SETTINGS: Retained speeds from ripple_07.  Reduced extrusion flow rate by decreasing filament diameter setting to 1.60mm.  OBSERVATIONS: No substantial change from ripple_07 results.ripple_09:  SETTINGS: Revalidation print of new filament roll using same settings and gcode file as ripple_02. OBSERVATIONS: Some loss of sheen from ripple_02. No difference in ripple effect other than that attributed to loss of surface sheen from the new filament.ripple_10:  SETTINGS: Same increased print speed as ripple_07.  Filament temp reduced from 220 to 205 degrees.  OBSERVATIONS: Near total loss of surface sheen.  Ripple barely perceptible. Significant degradation in corner quality.ripple_11:  SETTINGS: Per baseline but filament temp increased from 220 to 230 degrees.  OBSERVATIONS: Improved surface sheen. Ripple effect more apparent.ripple_12:  SETTINGS: Per baseline except combination of increased speeds from ripple_07, X and Y acceleration reduced from 750 to 200 mm/sec per second, XY Jerk reduced from 20 to 10 mm/sec. OBSERVATIONS:  Ripple effect reduced from that observed in ripple_07. Compression of ripple noted in same acceleration settings of ripple_04 not apparent.ripple_13:  SETTINGS: Per baseline except object rotated 45 degrees so perimeters do not fall in X or Y planes.  OBSERVATIONS: This one is tough to gauge due to a change in surface sheen. Some surfaces show no change in ripple effect.  Others show a reduction in ripple, but also a difference in sheen.ripple 14:  SETTINGS: Per baseline except parameter dropsegments in configuration_adv.h reduced from 5 to 1.  The dropsegments parameter instructs Marlin to skip or drop any line segments with step counts less than this value. Code comments do not explain why this is done.  OBSERVATIONS: No change in ripple effect noted.ripple_15:  SETTINGS: Per baseline except perimeter print speeds reduced from 50 mm/sec to 35 mm/sec. OBSERVATIONS: ripple appears to be compressed similar to ripple_04 and reduced acceleration settings.ripple_16:  SETTINGS: Per baseline except layer height increased from 0.20mm to 0.30mm.  OBSERVATIONS: Marked reduction in ripple.ripple_17:  SETTINGS: Revalidation print to baseline settings.  OBSERVATIONS: Ripple comparable to other baseline prints in ripple_02 and ripple_09.ripple_18:  SETTINGS: Per baseline except layer height increased from 0.20mm to 0.24mm. OBSERVATIONS: Some reduction in ripple effect, but not as reduced as in 0.30mm layer height in ripple_16.ripple_19: SETTINGS: Per baseline except layer height increased from 0.20mm to 0.28mm. OBSERVATIONS: Continued reduction in ripple from that observed at 0.24mm layer height. 
*
UNTESTED THOUGHTS*
Belt tightness.  Belts on the test printer are very tight.  It is interesting to note that some suggest reducing belt tension will reduce the ripple effect. For example, read the comments associated with this ripple test object: http://www.thingiverse.com/thing:277394Stretch/rubber-band effect in the beltsAttributed to beginning of belt flapping sometimes observed on trailing side of X and Y motor pulleysStepper motor drive levelLash in the extruder drive anywhere from extruder motor to filamentFlex in the hot end heat break as the nozzle drags on previous layer around corners, recesses, etc.Attributable to flaws in Marlin move planning for line segments involving acceleration. Is the acceleration between XY motors and the extruder motor properly coordinated?Possible flex in the M3 screws used to attach belt ends to the X-carriageMotor source voltage fluctuating axis and extruder motors both work to accelerate, possibly caused by varying voltage drop in RAMPS polyfuse 

*FINDINGS AND CONCLUSIONS*
Bear in mind that there may multiple causes of the ripple effect.  Perhaps different causes result in different effects on different printers.  Results from one machine such as my printer may not apply to other printers.It could also be that the ripple is a resonation effect formed from the composite of multiple causes.The ripple effect is not a result of the 2mm tooth spacing on the i3v motor pulleys, belts, or idler wheels.  If it was, the pattern of the effect would be constant, and would not be affected by changes in jerk, acceleration, or print speeds.Testing here suggests that the connection between ripple and XY Jerk or XY acceleration factors may not be as strong as typically thought.  Here, reductions in XY acceleration seemed to compress the ripple more than reduce it.  The momentum gained during lateral axis movement resulting from surface lettering and other shallow recesses has to be minimal considering the effects of acceleration.  Yet the ripple effect on these minimal movements is just as pronounced as on 90 degree corners.  Although not captured as part of these test results, the ripple effect can occur on recesses such as lettering on round corners.  If the ripple was caused by something happening in the X and Y axes, it seems reasonable to assume that the observed effect would vary depending on the incidence angle of the lettering with respect to the X and Y axes.Leave open the possibility that the ripple may be something non-mechanical.  Without a microscope or other means to inspect the ripple at a near-molecular level, it's hard to tell what the ripple really is.  I can't feel it on the test prints. Carefully inspecting some of the prints, the dark and light waves of the ripple seemed to switch - much like the effect of tilting a prismatic picture back and forth. Is the extrusion simply being imprinted with some iridescent effect? We all know the sheen of PLA can vary.  Couldn't something be occurring during extrusion that causes the sheen to vary in the pattern of the ripple?  Test results here related to changing the extrusion temperature or layer height somewhat validate this premise.Reducing the XY Jerk, XY acceleration, and/or print speed can reduce the effect of the ripple by reducing the duration length on the print.  The slower nozzle movements associated with these can lead to their own degradation in print quality, so there's a bit of a trade to be made.Increasing the print speed surprisingly shows promise as a way to reduce the ripple appearance by stretching out the duration of the ripple.There may be a connection the hot end flow rate and the ripple pattern.  Testing here suggests significant reduction in ripple by increasing the layer height.  One user has reported to me little or no ripple effect is apparent on prints made with a 0.30mm nozzle. Is the effect attributable to a vacillation in hot end pressure or temperature as the extruder decelerates to and accelerates from corners and recesses? 

FOLLOWUP COMMENT:  Meh. I may have wasted a lot of time on this.  A new roll of black PLA I obtained prints at a high gloss sheen at much lower temperatures than the second roll I was using in the ripple tests.  I don't plan to repeat all the tests, but running one print at 0.28mm layer height and 80mm/sec perimeter speeds with this new filament printed 15 degrees cooler showed little or no improvement from the baseline print.

----------


## beerdart

Can you share the .STL

----------


## printbus

> Can you share the .STL



http://www.thingiverse.com/thing:678295

I had intended to publish the object after the thread updates were complete, but ended up distracted for a while.  The Part 1 post has also been updated with a link.  

Here is another object AbuMaia pointed out - http://www.thingiverse.com/thing:277394

----------


## pichuete

> I am working through the stepper driver adjustments and have done them all except the extruder at this point.
> 
> My point in sharing that is to say that I am amazed at how much quieter they run when being driven properly!


do you have rambo board? im also trying to get the "right" values for stepper current . my printer is very noisy but increasing the current only seems to get it worse for me . im currently at {110,110,135,120,100}.

----------


## printbus

> do you have rambo board? im also trying to get the "right" values for stepper current . my printer is very noisy but increasing the current only seems to get it worse for me . im currently at {110,110,135,120,100}.


I realize the question is directed at N5QM, but try reducing the drive current instead.  As you are finding, increasing the motor drive current will increase the noise. To determine an "adequate" drive level, you can either start at minimum and increase the drive until the motor no longer skips, or start high and decrease the drive until it starts to skip.  Then increase the drive current some from that setting in order to provide some margin.  

But yeah, if N5QM or anyone else has figured out their digital values for use on RAMBO adjusted this way, go ahead and post them.

----------


## N5QM

> do you have rambo board? im also trying to get the "right" values for stepper current . my printer is very noisy but increasing the current only seems to get it worse for me . im currently at {110,110,135,120,100}.


No sir, I am using a RAMPS board, so wouldn't be of much help with a RAMBO.  I did notice a substantial difference in volume, especially on the Z axis.

----------


## squirrel

Hey Printbus! Just wanted to say a quick thank you for documenting and publishing your research! Amazing work, reads like an academic paper in a peer reviewed journal, and some of my friend's dissertations weren't as thoroughly written  :Big Grin:  So thank you and hope you continue your experiments!

----------


## printbus

> Hey Printbus! Just wanted to say a quick thank you for documenting and publishing your research! Amazing work, reads like an academic paper in a peer reviewed journal, and some of my friend's dissertations weren't as thoroughly written  So thank you and hope you continue your experiments!


Thanks for the feedback. Feel free to post an update when you are ready that summarizes where the thread led you to make changes that worked for you, etc.

----------


## squirrel

Ah well i can try! Only had the i3 since start of january, got it as a kit and built it myself. Was rather confused by it all at first, particularly the marlin settings. Found a lot of examples settings online but no explanation as to why they should be those values so found your write ups extremely useful. 

So using your values as a proven baseline i did some experimenting although i was never great at experimental write ups... So ill go through the settings and try to explain how i arrived at the values. 

HOMING_FEEDRATE  - I've kept same as your settings recap post

DEFAULT_MAX_FEEDRATE {400, 400, 2, 200} I know the x and y speed seems excessive but i haven't noticed any skipping. I know you've done the math but I'm a rebel  :Smile:  I also have a direct drive extruder which seems to be pretty strong and i haven't had any skipping or grinding issues at this speed either. Although I don't print at over 90mm/s, with travel moves set at 250mm/s. 

DEFAULT_MAX_ACCELERATION {6000,4500,400,500} I've experimented with different acceleration settings to try to deal with ringing (ripples) and found that for me, higher max acceleration combined with higher default acceleration made the ripples less noticeable. Or at least it seems that way. Y acceleration is set lower than x as the print bed is 6mm aluminium with a glass plate and seemed like a good idea to have it set lower.
DEFAULT_ACCELERATION 2000 Set any higher and y starts to skip steps, on travel moves i think, as they're the fastest.
DEFAULT_RETRACT_ACCELERATION 1000
DEFAULT_XYJERK 30
DEFAULT_ZJERK 10
DEFAULT_EJERK 10

I haven't done any proper experimenting to try to figure out what affects ringing, but turning acceleration up seemed to have worked some for me. Im printing out an adjustable x belt tensioner so i can easily adjust the belt to see how it affects the ripples. I feel like the key is figuring out a balance between print speed, default acceleration and jerk settings. What annoys me the most aren't the ripples but intact corners,slightly protruding, as if the filament kept flowing in one direction as the print path turned 90 degrees. Turning down the jerk settings leaves the corners less sharp, the only other options seems like printing slower so will try that next.

----------


## printbus

Thanks for contributing! With so many combinations now of printer sizes and types of electronics in the MakerFarm printers, it may be getting tough to compare results from one printer to another. 




> ...DEFAULT_MAX_FEEDRATE {400, 400, 2, 200} I know the x and y speed seems excessive but i haven't noticed any skipping. I know you've done the math but I'm a rebel  I also have a direct drive extruder which seems to be pretty strong and i haven't had any skipping or grinding issues at this speed either. Although I don't print at over 90mm/s, with travel moves set at 250mm/s.


Have you looked at the gcode in a viewer like gcode.ws?  I'd be curious to know what the  highest speed is that you see in the gcode viewer for any sort of path.  If I understand you correctly, you're likely not buying anything with the 400 values for XY in DEFAULT_MAX_FEEDRATE.  The slicer will be keeping it lower than that for the 90mm/sec print speed and 250mm/sec move speeds.  




> DEFAULT_MAX_ACCELERATION {





> 6000,4500,400,500} I've experimented with different acceleration settings to try to deal with ringing (ripples) and found that for me, higher max acceleration combined with higher default acceleration made the ripples less noticeable. Or at least it seems that way. Y acceleration is set lower than x as the print bed is 6mm aluminium with a glass plate and seemed like a good idea to have it set lower.


You've touched on something I've been wondering about.  Almost all the non-MakerFarm printers I've read about use pretty high acceleration rates.  I know in my ripple testing I also noticed that the ripple effect was less noticeable with a higher acceleration value. This made sense in a way since faster acceleration might cause the printer to pass-through whatever the root ripple issue is quicker.  People always talk about slowing down acceleration as a way to reduce the ripple. I've been wondering what the results would be if we went the other way and really, really cranked it up.  As long as print quality meets expectations, go for it. 




> DEFAULT_ACCELERATION 2000 Set any higher and y starts to skip steps, on travel moves i think, as they're the fastest.


Note that because of the multiple ways Marlin allows acceleration to be set, this value of 2000 is actually limiting your values for XY in DEFAULT_MAX_ACCELERATION. They work together in a "whichever is lower takes precedence" relationship. Setting it to 2000 is still significant compared to the original MakerFarm settings.

----------


## squirrel

Ah, well, i don't have a MakerFarm i3. Its a Schufco kit and as far as component quality goes I've been very happy with it all and generally had a trouble free experience. 

I haven't used a gcode viewer other than the one in repetier host but what you're saying about slicer limiting speeds definitely makes sense. And the same goes for DEFAULT_ACCELERATION values, I've noticed that cranking it up really affects the travel movements where as turning down max acceleration didn't  seem to make a difference... The way i thought of it is that the default acceleration is the minimum acceleration and max is maximum. 

So think what i will try next is maybe decreasing the travel speed but increasing acceleration so that the travel moves are a bit slower at faster acceleration setting. Set at 4000, some of the travel moves are almost too fast for the eye to follow but the y motor skipped once. In my limited experience there has been a few counter intuitive setting/effect relationships so i wouldn't be surprised if acceleration vs ripples is another one .

----------

