<p>Feedrates are not 4-dimensional, and yes this makes them a bit inconsistent. But physically the 4-dimensional speed would not make any sense - for example, slowing down the E axis while speeding up the X axis would not maintain the same &quot;overall speed&quot; in any meaningful sense.</p>
<p>So, feedrates work differently for:</p>
<ul>
<li><p>Moves with a nonzero X, Y, or Z component: the feedrate is an ideal, desired speed in 3 dimensions, possibly limited by the max feedrates of each axis (including E) individually, as well as their acceleration profiles.</p>
</li>
<li><p>Extruder-only moves where X, Y, and Z components are all zero: the feedrate is an ideal, desired speed in one dimension: the E axis, and may be limited by the max feedrate and acceleration profile for the E axis.</p>
</li>
</ul>

CC BY-SA 4.0
2020-10-26T21:55:00.987Z
Aha!  I did wonder if that was the explanation for how Cura's "print speed" can be the same as the feedrate it uses for printing moves.  I guess it keeps things simple.  The 4D approach wouldn't be completely insane, but it would mean you'd have to continually adjust F to get a constant movement speed or constant extrusion rate.  (FWIW, specifying the end position and time fully determines the solution, so you couldn't actually slow down E while speeding up X)
bobtato
CC BY-SA 4.0
2020-10-26T21:20:20.287Z
2020-10-26T21:32:27.200Z
2020-10-26T21:32:27.200Z
R.. GitHub STOP HELPING ICE
<p>I want to programatically generate G-code for a (Marlin-based) Ultimaker 2+ printer, and I have been looking at the <a href="https://marlinfw.org/meta/gcode/" rel="nofollow noreferrer">Marlin documentation</a> and working G-code examples generated by Cura.</p>
<p>This has left me confused about exactly how Marlin interprets the feedrate (F) parameter in G-code commands.</p>
<p>If I move on a single axis (e.g. <code>G1 F7000 X10</code> or <code>G1 F200 E50</code>), then I assume F simply says how fast that axis should move (ignoring acceleration).</p>
<p>On CNC milling machines I've worked with, the same is true when moving on multiple axes – for instance, <code>G1 F1000 X10 Y10 Z10</code> would mean the <em>tool</em> moves at 1000mm/min, and therefore the <em>individual</em> axes are each moving at 693mm/min.  Which is good, because it means the feedrate doesn't depend on the direction of movement.</p>
<p>But a 3D printer has four axes (E, X, Y, Z), and Marlin only uses a single feedrate parameter.  So do I need to calculate that in four-dimensional space?  In other words,</p>
<p><span class="math-container">$F = \sqrt[4]{F_E^4 + F_X^4 + F_Y^4 + F_Z^4} ?$</span></p>
<p>If that is not correct, how <strong>is</strong> the feedrate related to the feedrates for the individual axes?.</p>

<marlin><g-code>
Details of Marlin's feedrate calculation
bobtato
# Details of Marlin's feedrate calculation

(Asked by: username_0 on 2020-10-26)

I want to programatically generate G-code for a (Marlin-based) Ultimaker 2+ printer, and I have been looking at the [Marlin documentation](https://marlinfw.org/meta/gcode/) and working G-code examples generated by Cura.

This has left me confused about exactly how Marlin interprets the feedrate (F) parameter in G-code commands.

If I move on a single axis (e.g. `G1 F7000 X10` or `G1 F200 E50`), then I assume F simply says how fast that axis should move (ignoring acceleration).

On CNC milling machines I've worked with, the same is true when moving on multiple axes – for instance, `G1 F1000 X10 Y10 Z10` would mean the *tool* moves at 1000mm/min, and therefore the *individual* axes are each moving at 693mm/min. Which is good, because it means the feedrate doesn't depend on the direction of movement.

But a 3D printer has four axes (E, X, Y, Z), and Marlin only uses a single feedrate parameter. So do I need to calculate that in four-dimensional space? In other words,

$F = \sqrt[4]{F\_E^4 + F\_X^4 + F\_Y^4 + F\_Z^4} ?$

If that is not correct, how **is** the feedrate related to the feedrates for the individual axes?.

**Tags:** marlin, g-code

---

## 1 answers

### Answer by username_1 on 2020-10-26. Score: 1

Feedrates are not 4-dimensional, and yes this makes them a bit inconsistent. But physically the 4-dimensional speed would not make any sense - for example, slowing down the E axis while speeding up the X axis would not maintain the same "overall speed" in any meaningful sense.

So, feedrates work differently for:

* Moves with a nonzero X, Y, or Z component: the feedrate is an ideal, desired speed in 3 dimensions, possibly limited by the max feedrates of each axis (including E) individually, as well as their acceleration profiles.
* Extruder-only moves where X, Y, and Z components are all zero: the feedrate is an ideal, desired speed in one dimension: the E axis, and may be limited by the max feedrate and acceleration profile for the E axis.

> **Comments:**
> **username_0**: Aha!  I did wonder if that was the explanation for how Cura's "print speed" can be the same as the feedrate it uses for printing moves.  I guess it keeps things simple.  The 4D approach wouldn't be completely insane, but it would mean you'd have to continually adjust F to get a constant movement speed or constant extrusion rate.  (FWIW, specifying the end position and time fully determines the solution, so you couldn't actually slow down E while speeding up X)  

---

