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]

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]

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]

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]

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]

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]

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.