<p>I have tried looking into the printer firmware to see how the <em>Acceleration</em> setting affects the machine movement. From what I could tell, <em>Acceleration</em> seemed to be implemented differently depending on what firmware I looked at and was also affected by what the settings used on the printer were.  I didn't look any further because writing different rules for every different firmware seemed like too much trouble. Maybe someone that knows more about this would know if most firmware uses the same calculations. </p>

<p>I suspect that the acceleration setting will not make a lot of difference to the time that the print takes.  They haven't seemed to make a difference on the small prints that I have done printing with slow speeds. If you were printing larger prints at faster speeds that had long paths where the nozzle had time to accelerate and decelerate then I suspect you would notice a bigger difference with the time.</p>

<p>I have found that the biggest error between the predicted time and the actual time has been the time the machine spends processing the instructions. When printing a model that has a lot of short movements that need to be sent to the printer and they need to be processed and calculated by the printer, I have noticed the printer will pause for a fraction of a second. It is not long enough to see a difference in the printers movements, but it is noticeable enough to hear. I suspect that on cheaper printers this would cause a bigger error than the acceleration. </p>

<p>If someone can find out how the acceleration settings are calculated by the printer and what G-code command can be used to get the acceleration settings out of the printer, I would be really interested in knowing more about this.</p>

CC BY-SA 4.0
2019-09-24T20:02:42.723Z
"I suspect that the acceleration setting will not make a lot of difference to the time that the print takes." <-- this couldn't be more wrong. Acceleration is the dominant factor in print time whenever the ration between print speed and detail size is high (i.e. fast speed setting or small details or both). So much that increasing the [max] speed setting by a factor of 2x is unlikely to make even a 5% reduction in print time.
R.. GitHub STOP HELPING ICE
CC BY-SA 3.0
2016-12-21T11:20:40.927Z
Thank you for your answer, I'll keep searching. Thanks for pointing me in the right direction: I can read the Marlin source code and search for the acceleration and jerk control parts, it will surely help, I didn't think about it! Thank you!
BackSlash
CC BY-SA 3.0
2016-12-20T22:48:44.373Z
2017-06-25T05:48:32.993Z
2017-06-25T05:48:32.993Z
user802599
<p>First of all, there are some nice open source analyzers written in JavaScript that you can use online, or read the source to, at <a href="https://www.gcodeanalyser.com/" rel="noreferrer">https://www.gcodeanalyser.com/</a> and <a href="http://gcode.ws/" rel="noreferrer">http://gcode.ws/</a>. Their predictions don't fully match actual printer firmware, but they do a reasonably close job, and reading them would be informative.</p>

<p>Basically, the story behind acceleration and jerk is that you can't change the velocity (speed or direction) of the print head instantaneously. It takes time to speed up and slow down. Acceleration is the max rate at which the velocity of the print head can change. Jerk is something of a misnomer/hack, and is the max fake-instantaneous change in velocity allowed at the junction of two segments/curves. The point of jerk is to avoid choppy motion when moving along a curve made up of many segments by accelerating/decelerating at each tiny corner. Note that there are two sets of settings for both acceleration and jerk:</p>

<ul>
<li><p>a maximum absolute value (3D vector length) that frequently changed as part of the gcode in order to use different acceleration profiles for print moves vs travel moves, walls vs infill, etc.</p></li>
<li><p>per-axis absolute values (standard 1D absolute value) for the limitations of the machine, that are usually set in the printer's settings or the start gcode profile for your printer and never changed.</p></li>
</ul>

<p>Movement is constrained to always respect both sets of settings.</p>

<p>Printer firmware uses acceleration and jerk settings along with <em>lookahead</em> at upcoming motion commands to decide how to actually operate the motors. When it starts a motion, it has to accelerate up to the configured max velocity within the acceleration constraints. It also has to start slowing back down midway through unless it knows the next motion is going to continue in the exact same direction; how much it has to slow down depends on the difference in the vectors of motion. If the next motion is going to be in approximately the same direction, it may be able to avoid slowing down by using the jerk allowance to make an "instantaneous" change of velocity at the corner. Only if you have long (relative to speed) linear or approximately linear motions will you ever actually reach the requested speed.</p>

<p>So, to estimate print time, you need to <em>model</em> this. Keep track of print head velocity while processing/simulating the gcode, and for each motion command, compute velocity as a function of time using the acceleration limits (accelerating at the max rate they allow). You also need to figure out the final velocity you want to end the motion with in order to be able to start the next motion command, and a point to start decelerating if necessary to reach that.</p>

CC BY-SA 4.0
2019-09-25T06:16:43.820Z
Jerk is the derivate of acceleration.
Trish
CC BY-SA 4.0
2019-09-25T10:32:20.190Z
@trish: except when it's not. See my question https://3dprinting.stackexchange.com/questions/10369/why-does-jerk-have-units-of-mm-s-rather-than-mm-s%c2%b3.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2019-09-24T20:23:55.003Z
2019-09-24T20:23:55.003Z
R.. GitHub STOP HELPING ICE
<p>I started to write an application that calculates the estimated total print time from the G-code file for an already sliced model.</p>

<p>The program works and it's pretty accurate.</p>

<p>It works as follows: </p>

<ol>
<li>It scans the entire G-code file to identify all of the movements</li>
<li>It calculates the time for each move by dividing segment distance by the speed in mm/s.</li>
</ol>

<p>Let's assume this is the G-code:</p>

<pre><code>G28 ; home all axes
G1 Z0.200 F5400.000
G1 X158.878 Y27.769 E6.65594 F900.000
</code></pre>

<p>This is the calculation it does:</p>

<pre><code>totalTime = 0

# G28 ; home all axes
currentX = 0 mm
currentY = 0 mm
currentZ = 0 mm

# G1 Z0.200 F5400.000
newZ = 0.2 mm
mmPerSecond = 5400 / 60 = 90 mm/s
deltaZ = newZ - currentZ = 0.2 - 0 = 0.2 mm
segmentLength = deltaZ  = 0.2 mm
moveTime = segmentLength / mmPerSecond = 0.2 / 90 = 0.002 s
totalTime = totalTime + moveTime = 0 + 0.002 = 0.002 s

# G1 X158.878 Y27.769 E6.65594 F900.000
newX = 158.878 mm
newY = 27.769 mm
mmPerSecond = 900 / 60 = 15 mm/s
deltaX = newX - currentX = 158.878 - 0 = 158.878 mm
deltaY = newY - currentY = 27.769 - 0  = 27.769 mm
segmentLength = square_root(deltaX² + deltaY²) = 161.287 mm
moveTime = deltaZ / mmPerSecond = 161.287 / 15 = 10.755 s
totalTime = totalTime + moveTime = 0.002 + 10.755 = 10.757 s
</code></pre>

<p>In this example, the print will take approximately 10.7 seconds.</p>

<p>More generally, the formula used is, for each movement:</p>

<pre><code>moveTime = segmentLength / mmPerSecond
</code></pre>

<p>By summing up all the move times, we have the total estimated print time.</p>

<p>I've seen that some forums state that the 3D print time also depends on some settings on the 3D printer, especially Acceleration X, Acceleration Y, Acceleration Z, Jerk, and Z-Jerk.</p>

<p>I'd like to make it possible to use those values to more accurately calculate print time; however, I don't understand how those values affect the move time:</p>

<ol>
<li>How should Acceleration and Jerk be considered; and, how do they speed up or slow down the print time?  </li>
<li>How should I edit my formula in order to include Acceleration and Jerk in the print time calculation?</li>
</ol>

CC BY-SA 4.0
2019-09-25T16:13:30.323Z
Maybe you could check slic3r and see how it calculates those parameters. I remember getting a time estimate when slicing.
FarO
CC BY-SA 4.0
2019-09-26T06:16:36.050Z
@FarO I use Slic3r and I didn't ever see a time estimation. Maybe I'm not looking at the right place but there are lots of users asking for that feature over the web so I'm afraid there is no way to know print time in Slic3r.
BackSlash
CC BY-SA 4.0
2019-09-26T08:35:27.207Z
@BackSlash I usually see it in Repetier at the end of the slicing in the output log. I guess then it's from Repetier itself!
FarO
CC BY-SA 3.0
2016-12-21T14:25:58.903Z
How acccurate do you need to be?  Yes you can plug in the accelerations, and compensate for short runs where the motors never reach full speed before decelerating, and so on, but if the net result is only off by, say, 2%, do you care?  Try printing something simple like a square pyramid and compare your prediction to reality.
Carl Witthoft
CC BY-SA 3.0
2016-12-21T17:37:33.373Z
I'd like to be as much precise as possible... Right now on a 9 hours print the difference between prediction and reality is 10-15 minutes, which is a lot. I'll look at marlin source code to find how acceleration and jerk are handled while printing
BackSlash
<g-code><estimation><acceleration>
Calculating the estimated print time of an already sliced file
BackSlash
# Calculating the estimated print time of an already sliced file

(Asked by: username_0 on 2016-12-20)

I started to write an application that calculates the estimated total print time from the G-code file for an already sliced model.
The program works and it's pretty accurate.
It works as follows: 

It scans the entire G-code file to identify all of the movements
It calculates the time for each move by dividing segment distance by the speed in mm/s.

Let's assume this is the G-code:
G28 ; home all axes
G1 Z0.200 F5400.000
G1 X158.878 Y27.769 E6.65594 F900.000

This is the calculation it does:
totalTime = 0

# G28 ; home all axes
currentX = 0 mm
currentY = 0 mm
currentZ = 0 mm

# G1 Z0.200 F5400.000
newZ = 0.2 mm
mmPerSecond = 5400 / 60 = 90 mm/s
deltaZ = newZ - currentZ = 0.2 - 0 = 0.2 mm
segmentLength = deltaZ  = 0.2 mm
moveTime = segmentLength / mmPerSecond = 0.2 / 90 = 0.002 s
totalTime = totalTime + moveTime = 0 + 0.002 = 0.002 s

# G1 X158.878 Y27.769 E6.65594 F900.000
newX = 158.878 mm
newY = 27.769 mm
mmPerSecond = 900 / 60 = 15 mm/s
deltaX = newX - currentX = 158.878 - 0 = 158.878 mm
deltaY = newY - currentY = 27.769 - 0  = 27.769 mm
segmentLength = square_root(deltaX² + deltaY²) = 161.287 mm
moveTime = deltaZ / mmPerSecond = 161.287 / 15 = 10.755 s
totalTime = totalTime + moveTime = 0.002 + 10.755 = 10.757 s

In this example, the print will take approximately 10.7 seconds.
More generally, the formula used is, for each movement:
moveTime = segmentLength / mmPerSecond

By summing up all the move times, we have the total estimated print time.
I've seen that some forums state that the 3D print time also depends on some settings on the 3D printer, especially Acceleration X, Acceleration Y, Acceleration Z, Jerk, and Z-Jerk.
I'd like to make it possible to use those values to more accurately calculate print time; however, I don't understand how those values affect the move time:

How should Acceleration and Jerk be considered; and, how do they speed up or slow down the print time?  
How should I edit my formula in order to include Acceleration and Jerk in the print time calculation?

**Tags:** g-code, estimation, acceleration
> **Comments:**
> **username_2**: How acccurate do you need to be?  Yes you can plug in the accelerations, and compensate for short runs where the motors never reach full speed before decelerating, and so on, but if the net result is only off by, say, 2%, do you care?  Try printing something simple like a square pyramid and compare your prediction to reality.  
> **username_0**: I'd like to be as much precise as possible... Right now on a 9 hours print the difference between prediction and reality is 10-15 minutes, which is a lot. I'll look at marlin source code to find how acceleration and jerk are handled while printing  
> **username_1**: Maybe you could check slic3r and see how it calculates those parameters. I remember getting a time estimate when slicing.  
> **username_0**: @FarO I use Slic3r and I didn't ever see a time estimation. Maybe I'm not looking at the right place but there are lots of users asking for that feature over the web so I'm afraid there is no way to know print time in Slic3r.  
> **username_1**: @BackSlash I usually see it in Repetier at the end of the slicing in the output log. I guess then it's from Repetier itself!  

---

## 2 answers

### Answer by username_4 on 2019-09-24. Score: 6

First of all, there are some nice open source analyzers written in JavaScript that you can use online, or read the source to, at <https://www.gcodeanalyser.com/> and <http://gcode.ws/>. Their predictions don't fully match actual printer firmware, but they do a reasonably close job, and reading them would be informative.

Basically, the story behind acceleration and jerk is that you can't change the velocity (speed or direction) of the print head instantaneously. It takes time to speed up and slow down. Acceleration is the max rate at which the velocity of the print head can change. Jerk is something of a misnomer/hack, and is the max fake-instantaneous change in velocity allowed at the junction of two segments/curves. The point of jerk is to avoid choppy motion when moving along a curve made up of many segments by accelerating/decelerating at each tiny corner. Note that there are two sets of settings for both acceleration and jerk:

* a maximum absolute value (3D vector length) that frequently changed as part of the gcode in order to use different acceleration profiles for print moves vs travel moves, walls vs infill, etc.
* per-axis absolute values (standard 1D absolute value) for the limitations of the machine, that are usually set in the printer's settings or the start gcode profile for your printer and never changed.

Movement is constrained to always respect both sets of settings.

Printer firmware uses acceleration and jerk settings along with *lookahead* at upcoming motion commands to decide how to actually operate the motors. When it starts a motion, it has to accelerate up to the configured max velocity within the acceleration constraints. It also has to start slowing back down midway through unless it knows the next motion is going to continue in the exact same direction; how much it has to slow down depends on the difference in the vectors of motion. If the next motion is going to be in approximately the same direction, it may be able to avoid slowing down by using the jerk allowance to make an "instantaneous" change of velocity at the corner. Only if you have long (relative to speed) linear or approximately linear motions will you ever actually reach the requested speed.

So, to estimate print time, you need to *model* this. Keep track of print head velocity while processing/simulating the gcode, and for each motion command, compute velocity as a function of time using the acceleration limits (accelerating at the max rate they allow). You also need to figure out the final velocity you want to end the motion with in order to be able to start the next motion command, and a point to start decelerating if necessary to reach that.

> **Comments:**
> **username_5**: Jerk is the derivate of acceleration.  
> **username_4**: @trish: except when it's not. See my question https://3dprinting.stackexchange.com/questions/10369/why-does-jerk-have-units-of-mm-s-rather-than-mm-s%c2%b3.  

---

### Answer by username_3 on 2016-12-20. Score: 5

I have tried looking into the printer firmware to see how the *Acceleration* setting affects the machine movement. From what I could tell, *Acceleration* seemed to be implemented differently depending on what firmware I looked at and was also affected by what the settings used on the printer were. I didn't look any further because writing different rules for every different firmware seemed like too much trouble. Maybe someone that knows more about this would know if most firmware uses the same calculations.

I suspect that the acceleration setting will not make a lot of difference to the time that the print takes. They haven't seemed to make a difference on the small prints that I have done printing with slow speeds. If you were printing larger prints at faster speeds that had long paths where the nozzle had time to accelerate and decelerate then I suspect you would notice a bigger difference with the time.

I have found that the biggest error between the predicted time and the actual time has been the time the machine spends processing the instructions. When printing a model that has a lot of short movements that need to be sent to the printer and they need to be processed and calculated by the printer, I have noticed the printer will pause for a fraction of a second. It is not long enough to see a difference in the printers movements, but it is noticeable enough to hear. I suspect that on cheaper printers this would cause a bigger error than the acceleration.

If someone can find out how the acceleration settings are calculated by the printer and what G-code command can be used to get the acceleration settings out of the printer, I would be really interested in knowing more about this.

> **Comments:**
> **username_0**: Thank you for your answer, I'll keep searching. Thanks for pointing me in the right direction: I can read the Marlin source code and search for the acceleration and jerk control parts, it will surely help, I didn't think about it! Thank you!  
> **username_4**: "I suspect that the acceleration setting will not make a lot of difference to the time that the print takes." <-- this couldn't be more wrong. Acceleration is the dominant factor in print time whenever the ration between print speed and detail size is high (i.e. fast speed setting or small details or both). So much that increasing the [max] speed setting by a factor of 2x is unlikely to make even a 5% reduction in print time.  

---

