<p>Stepper motors &quot;want&quot; to keep their position as they are told to by the firmware, therefore they do whatever it's needed (accelerate and brake) to follow the orders they received.</p>
<p>The question is: is the firmware telling them to move/accelerate/brake faster/harder than they can? if yes, they won't keep up (because of inertia and much more) so you'll see artefacts. If not, they will follow the orders exactly (well, mostly, but it's not important now) and no distortions will be there.</p>
<p>Whether they keep up or not is up to you: you are setting their power (the motor current) and you are telling them how fast/hard to move/accelerate/brake. If you push them too much, the motors will try... and fail to keep up. That's why you have max acceleration, speed, jerk in the firmware and in the slicer.</p>
<p>Additional info: even if the motors keep the position as they are told to, the motors have no knowledge of anything past them: belts, leadscrews, and so on.</p>
<p>Imagine the X axis belt (which connects the motor to the printing head) is made of an elastic band: the motors will be where you order them to be, but the inertia of the printing head will stretch the elastic band and the printing head will NOT be where you expect it to be.</p>
<p>It is again up to you to reduce the max acceleration to a value below what the motors could be able to do, if needed. Motors are often not pushed to their limit also because other factors cause issues before the motors fail.</p>
<p>How to know how much to limit the acceleration and speed? the only way is trying.</p>

CC BY-SA 4.0
2021-02-11T22:16:08.177Z
The rubberband example actually uses inertia in the non-physical way. The rubber band acts as a spring, so any happening is delayed by a factor of the length of the band and the spring coefficient of it
Trish
CC BY-SA 4.0
2021-02-12T10:09:01.387Z
@Trish it may not be completely rigorous, but I think it answers the question in a quite clear way for people not particularly versed in physics :)
FarO
CC BY-SA 4.0
2021-02-11T21:41:20.303Z
2021-02-11T21:41:20.303Z
FarO
<h1>Inertia is not what you think it is</h1>
<p>Inertia is technically speaking something that in physics is not what you commonly understand under the term. There is no mysterious &quot;Inertia Force&quot; that slows your actions on a setup. Inertia is not what makes you overshoot a print's endpoint.</p>
<p>Inertia is just the principle <em>why</em> you need to <em>break</em> (negative acceleration) before you reach the endpoint of travel and how much you need to and <em>how fast you can step on the break</em> (jerk).</p>
<h2>Recap on Newtonian Motion Mechanics</h2>
<p>Inertia is the fact that an item that is under movement and does not get acted upon just does nothing, as Newton's first law prescribes. That your applied force only takes effect on a body over time (the <em>common</em> thing understood under inertia) follows directly from the description of the 2nd Law of Newtonian Mechanics:</p>
<blockquote>
<p>Mutationem motus proportionalem esse vi motrici impressae, et fieri secundum
lineam rectam qua vis illa imprimitur.</p>
</blockquote>
<blockquote>
<p>The alteration of motion is ever proportional to the motive force impressed; and is
made in the direction of the right line in which that force is impressed.</p>
</blockquote>
<p><span class="math-container">$$F=\frac{d}{dt} (m\times v)$$</span></p>
<p>The <strong>F</strong>orce onto a body is the change over time(<span class="math-container">$\frac{d}{dt}$</span>) of <strong>m</strong>ass and <strong>v</strong>elocity. In the classics physical case with constant mass, this becomes the much more well known formulation: <span class="math-container">$$F=m\times \frac{d}{dt} v=m\times\dot v=m\times a$$</span></p>
<p>Now, we have an item of known mass and a known initial velocity <span class="math-container">$v_0$</span>. The speed of the item at any moment is thus <span class="math-container">$$v(t)=v_0-(\frac F m\times t)=v_0-(a\times t)$$</span></p>
<h3>Momentum</h3>
<p>Another thing that is often mingled into the therm inertia is actually the momentum of an item. It follows directly from the newton text: the force is proportional to the change of momentum. <span class="math-container">$$F=\frac{d}{dt}p=\frac{d}{dt}(m\times v)$$</span><span class="math-container">$$p=m\times v$$</span> Momentum can be best understood as an amount of &quot;energy&quot; (it's not, energy is <span class="math-container">$E_\text{kin}=m\times v^2$</span>)</p>
<h1>The <em>principle of inertia</em> is looked at in the slicer</h1>
<p>Most slicers set a <em>maximum acceleration</em> for machines and <em>jerk</em> for machines. These values are decided based on the mass of the printhead: Maximum acceleration times the mass of the printhead is the maximum force. <a href="https://en.wikipedia.org/wiki/Jerk_(physics)" rel="nofollow noreferrer">Jerk is the derivate of acceleration over time</a>, so it flows into motion mechanics back as <span class="math-container">$F(t)=m\times j\times t$</span>. So choosing the Jerk and Max-acceleration does include information about the mass of the printhead, without expressly stating it.</p>
<p>One <em>could</em> write the code in reverse and decide on a maximum allowable <strong>Force</strong> and include the mass of the printhead, resulting in automatically calculated settings for the maximum allowable 2nd and 3rd derivate of the position, acceleration and jerk.</p>
<h1>Printer control boards just throttle</h1>
<p>Likewise, printer control boards just throttle acceleration and jerk to a value in their firmware. They don't need to know the mass of the printhead if they put maximum values on both, and those account for the behavior wanted.</p>
<p>There is no accuracy to be gained from doing the calculation the other way around in the firmware: Even knowing the mass and some allowable force would not get you any way closer but spend quite some code on a function that is called for a few static values.</p>
<p>What is more influential, the acceleration and jerk settings are very heavily influenced by how your printhead is mounted, not just the mass of the printhead: Do you have a feather mounted on linear rails and moved with a screw? Or do we have a kilo chunk of lead mounted on a cross of 2 mm aluminium rod rails, pulled with a super soft rubber twist?</p>

CC BY-SA 4.0
2021-02-11T14:12:50.350Z
I think I was using inertia properly. I mean, for example, that once the print head is moving it might overshoot its position objective. The Jerk settings do speak to what I'm talking about. Do they just have a flat estimate of the mass?
ZECTBynmo
CC BY-SA 4.0
2021-02-11T18:33:52.367Z
@ZECTBynmo "Overshooting" is exactly why I said you understand inertia wrong. You need to just reduce the max acceleration and jerk.
Trish
CC BY-SA 4.0
2021-02-11T18:50:00.427Z
Thanks for the responses. I understand the comments about jerk and max acceleration - although my question about how those settings are setup is not answered. Are there any controllers that dynamically measure mass constants for those values? Also, your comments about inertia don't make sense to me - those jerk settings are specifically to correct for the effects of inertia I'm talking about, no?
ZECTBynmo
CC BY-SA 4.0
2021-02-11T19:00:53.153Z
Anyway thanks for pointing me in the direction of jerk/acceleration limits. I'll see if I can find projects that dig into setting those dynamically.
ZECTBynmo
CC BY-SA 4.0
2021-02-11T19:11:02.733Z
@ZECTBynmo let me put something straight: to calculate all those values (e.g. deforming of rails etc.) influencing the actual movement path in *real time*, your machine would need to model the behavior of the whole machine in every moment. That is a task for a supercomputer. I am not aware of any commonly used firmware that even would *allow* to set a mas value for the printhead, let alone use that to calculate anything.
Trish
CC BY-SA 4.0
2021-02-11T19:13:10.113Z
The jerk and acceleration limits are there to limit overshooting, yes. By setting those, you effectively make sure that the changes in printhead direction come more gradual and the printhead has to break further from the corner.
Trish
CC BY-SA 4.0
2021-02-11T19:23:44.843Z
Okay, I think we're talking past each other. Thanks for the help!
ZECTBynmo
CC BY-SA 4.0
2021-02-11T14:07:10.600Z
2021-02-11T19:17:05.827Z
2021-02-11T19:17:05.827Z
Trish
<p>I've never built a 3D printer before, but I understand dynamical systems and control theory, and I imagine a lot of the distortion/inaccuracy that happens during the FDM process (especially at high speeds) is due to position inaccuracies because of inertia. For example, a heavy print head moving fast enough might overshoot its position target if the system expects it to stop instantly. Does any existing 3D printer controller software try to measure the mass of the print head/movement assembly and then use that to come up with better movement instructions?</p>
<p>To speculate a bit: This additional accuracy might not be useful with many normal stepper-driven printers because they lack resolution and/or control, but I think in some cases it would. I imagine with enough positional accuracy and acceleration control you could model the print head position with a dynamical system and get extremely precise movement right up to the mechanical limits of the system.</p>
<p>Am I wrong that inertia has a large effect? Would this be theoretically impossible for some reason I'm not thinking about?</p>

CC BY-SA 4.0
2021-02-11T16:42:25.840Z
What printers usually end up with is oscillation when turning corners, so that you will see a wave pattern in prints.
Perry Webb
CC BY-SA 4.0
2021-02-12T02:16:13.223Z
For what it's worth, most printers try very hard to avoid having a "heavy print head", but a moving bed (which many do have) ends up being the same thing. CoreXY and delta machines, however, tend to have no fast-moving parts with significant mass.
R.. GitHub STOP HELPING ICE
<print-quality><g-code><stepper-driver><motor><speed>
Do printer controllers take inertia into account when interpreting G-code into movement instructions?
ZECTBynmo
# Do printer controllers take inertia into account when interpreting G-code into movement instructions?

(Asked by: username_0 on 2021-02-11)

I've never built a 3D printer before, but I understand dynamical systems and control theory, and I imagine a lot of the distortion/inaccuracy that happens during the FDM process (especially at high speeds) is due to position inaccuracies because of inertia. For example, a heavy print head moving fast enough might overshoot its position target if the system expects it to stop instantly. Does any existing 3D printer controller software try to measure the mass of the print head/movement assembly and then use that to come up with better movement instructions?

To speculate a bit: This additional accuracy might not be useful with many normal stepper-driven printers because they lack resolution and/or control, but I think in some cases it would. I imagine with enough positional accuracy and acceleration control you could model the print head position with a dynamical system and get extremely precise movement right up to the mechanical limits of the system.

Am I wrong that inertia has a large effect? Would this be theoretically impossible for some reason I'm not thinking about?

**Tags:** print-quality, g-code, stepper-driver, motor, speed
> **Comments:**
> **username_1**: What printers usually end up with is oscillation when turning corners, so that you will see a wave pattern in prints.  
> **username_2**: For what it's worth, most printers try very hard to avoid having a "heavy print head", but a moving bed (which many do have) ends up being the same thing. CoreXY and delta machines, however, tend to have no fast-moving parts with significant mass.  

---

## 2 answers

### Answer by username_3 on 2021-02-11. Score: 2

Stepper motors "want" to keep their position as they are told to by the firmware, therefore they do whatever it's needed (accelerate and brake) to follow the orders they received.

The question is: is the firmware telling them to move/accelerate/brake faster/harder than they can? if yes, they won't keep up (because of inertia and much more) so you'll see artefacts. If not, they will follow the orders exactly (well, mostly, but it's not important now) and no distortions will be there.

Whether they keep up or not is up to you: you are setting their power (the motor current) and you are telling them how fast/hard to move/accelerate/brake. If you push them too much, the motors will try... and fail to keep up. That's why you have max acceleration, speed, jerk in the firmware and in the slicer.

Additional info: even if the motors keep the position as they are told to, the motors have no knowledge of anything past them: belts, leadscrews, and so on.

Imagine the X axis belt (which connects the motor to the printing head) is made of an elastic band: the motors will be where you order them to be, but the inertia of the printing head will stretch the elastic band and the printing head will NOT be where you expect it to be.

It is again up to you to reduce the max acceleration to a value below what the motors could be able to do, if needed. Motors are often not pushed to their limit also because other factors cause issues before the motors fail.

How to know how much to limit the acceleration and speed? the only way is trying.

> **Comments:**
> **username_4**: The rubberband example actually uses inertia in the non-physical way. The rubber band acts as a spring, so any happening is delayed by a factor of the length of the band and the spring coefficient of it  
> **username_3**: @Trish it may not be completely rigorous, but I think it answers the question in a quite clear way for people not particularly versed in physics :)  

---

### Answer by username_4 on 2021-02-11. Score: 0

# Inertia is not what you think it is

Inertia is technically speaking something that in physics is not what you commonly understand under the term. There is no mysterious "Inertia Force" that slows your actions on a setup. Inertia is not what makes you overshoot a print's endpoint.

Inertia is just the principle *why* you need to *break* (negative acceleration) before you reach the endpoint of travel and how much you need to and *how fast you can step on the break* (jerk).

## Recap on Newtonian Motion Mechanics

Inertia is the fact that an item that is under movement and does not get acted upon just does nothing, as Newton's first law prescribes. That your applied force only takes effect on a body over time (the *common* thing understood under inertia) follows directly from the description of the 2nd Law of Newtonian Mechanics:

> Mutationem motus proportionalem esse vi motrici impressae, et fieri secundum
> lineam rectam qua vis illa imprimitur.

> The alteration of motion is ever proportional to the motive force impressed; and is
> made in the direction of the right line in which that force is impressed.

$$F=\frac{d}{dt} (m\times v)$$

The **F**orce onto a body is the change over time($\frac{d}{dt}$) of **m**ass and **v**elocity. In the classics physical case with constant mass, this becomes the much more well known formulation: $$F=m\times \frac{d}{dt} v=m\times\dot v=m\times a$$

Now, we have an item of known mass and a known initial velocity $v\_0$. The speed of the item at any moment is thus $$v(t)=v\_0-(\frac F m\times t)=v\_0-(a\times t)$$

### Momentum

Another thing that is often mingled into the therm inertia is actually the momentum of an item. It follows directly from the newton text: the force is proportional to the change of momentum. $$F=\frac{d}{dt}p=\frac{d}{dt}(m\times v)$$$$p=m\times v$$ Momentum can be best understood as an amount of "energy" (it's not, energy is $E\_\text{kin}=m\times v^2$)

# The *principle of inertia* is looked at in the slicer

Most slicers set a *maximum acceleration* for machines and *jerk* for machines. These values are decided based on the mass of the printhead: Maximum acceleration times the mass of the printhead is the maximum force. [Jerk is the derivate of acceleration over time](https://en.wikipedia.org/wiki/Jerk_(physics)), so it flows into motion mechanics back as $F(t)=m\times j\times t$. So choosing the Jerk and Max-acceleration does include information about the mass of the printhead, without expressly stating it.

One *could* write the code in reverse and decide on a maximum allowable **Force** and include the mass of the printhead, resulting in automatically calculated settings for the maximum allowable 2nd and 3rd derivate of the position, acceleration and jerk.

# Printer control boards just throttle

Likewise, printer control boards just throttle acceleration and jerk to a value in their firmware. They don't need to know the mass of the printhead if they put maximum values on both, and those account for the behavior wanted.

There is no accuracy to be gained from doing the calculation the other way around in the firmware: Even knowing the mass and some allowable force would not get you any way closer but spend quite some code on a function that is called for a few static values.

What is more influential, the acceleration and jerk settings are very heavily influenced by how your printhead is mounted, not just the mass of the printhead: Do you have a feather mounted on linear rails and moved with a screw? Or do we have a kilo chunk of lead mounted on a cross of 2 mm aluminium rod rails, pulled with a super soft rubber twist?

> **Comments:**
> **username_0**: I think I was using inertia properly. I mean, for example, that once the print head is moving it might overshoot its position objective. The Jerk settings do speak to what I'm talking about. Do they just have a flat estimate of the mass?  
> **username_4**: @ZECTBynmo "Overshooting" is exactly why I said you understand inertia wrong. You need to just reduce the max acceleration and jerk.  
> **username_0**: Thanks for the responses. I understand the comments about jerk and max acceleration - although my question about how those settings are setup is not answered. Are there any controllers that dynamically measure mass constants for those values? Also, your comments about inertia don't make sense to me - those jerk settings are specifically to correct for the effects of inertia I'm talking about, no?  
> **username_0**: Anyway thanks for pointing me in the direction of jerk/acceleration limits. I'll see if I can find projects that dig into setting those dynamically.  
> **username_4**: @ZECTBynmo let me put something straight: to calculate all those values (e.g. deforming of rails etc.) influencing the actual movement path in *real time*, your machine would need to model the behavior of the whole machine in every moment. That is a task for a supercomputer. I am not aware of any commonly used firmware that even would *allow* to set a mas value for the printhead, let alone use that to calculate anything.  
> **username_4**: The jerk and acceleration limits are there to limit overshooting, yes. By setting those, you effectively make sure that the changes in printhead direction come more gradual and the printhead has to break further from the corner.  
> **username_0**: Okay, I think we're talking past each other. Thanks for the help!  

---

