<p>Generally speaking, the typical algorithm takes into account the slicer's speed settings for specific features of the build, such as infill, perimeters, top/bottom layers, etc. The distance traveled by the nozzle at a specific speed for each feature is also part of the equations involved. There are some rather vague portions of the nozzle movement based on acceleration and other factors which makes the calculations less accurate.</p>

<blockquote>
  <p>How accurate is it?</p>
</blockquote>

<p>Not too accurate. My experience with three different slicers is that it's never been within better than ten percent. I believe the various combinations of features of a build are not going to be identical from one model to the next, preventing even a ballpark figure to be created from previous builds.</p>

CC BY-SA 3.0
2017-08-09T01:14:11.747Z
Can you provide a reference where one could see how these calculations are made ? Like a piece of code or the algorithm itself.
GSH
CC BY-SA 3.0
2017-08-09T11:01:47.237Z
Tom van der Zanden's answer is a bit more convoluted than I can follow, not being a code person, but is a good start. I've found a number of web sites containing basic descriptions of calculations, including http://forums.reprap.org/read.php?2,647001 but all of them appear to be missing various factors. In most of the sites, the acceleration is ignored or approximated. As a result, the build times are approximations. I suppose if one were applying orbital dynamics mathematics to 3D printing, one could get more accurate results.
fred_dot_u
CC BY-SA 3.0
2017-08-09T12:54:42.383Z
Unless you're dealing with multi-day prints, I'd say 10% is more than adequate accuracy.
Carl Witthoft
CC BY-SA 3.0
2017-08-09T00:06:09.160Z
2017-08-09T00:06:09.160Z
fred_dot_u
<p>Much of the software used in 3D printing is open-source, and so are some slicers. Cura, for instance, does (or did, this source code is from an older branch) its print time estimation in <a href="https://github.com/smorloc/Curation/blob/master/Cura/util/gcodeInterpreter.py" rel="noreferrer">gcodeInterpreter.py</a>.</p>

<p>The relevant portion of the source code is (simplified and with many lines removed for clarity):</p>

<pre><code>    totalMoveTimeMinute = 0.0
    pos = util3d.Vector3()

    for line in gcodeFile:
        G = self.getCodeInt(line, 'G')
        if G is not None:
            if G == 0 or G == 1:    #Move
                x = self.getCodeFloat(line, 'X')
                y = self.getCodeFloat(line, 'Y')
                z = self.getCodeFloat(line, 'Z')
                e = self.getCodeFloat(line, 'E')
                f = self.getCodeFloat(line, 'F')
                oldPos = pos.copy()
                pos.x = x
                pos.y = y
                pos.z = z
                feedrate = f
                currentE = e

                totalMoveTimeMinute += (oldPos - pos).vsize() / feedRate
</code></pre>

<p>As you can see, (this version of) Cura simply:</p>

<ul>
<li><p>Loops over all the G-code instructions,</p></li>
<li><p>Computes the length of each move (in X/Y/Z) and divides that by the feedrate to get the time that move will take,</p></li>
<li><p>Sums this up over all the moves.</p></li>
</ul>

<p>and does not take into account:</p>

<ul>
<li><p>Acceleration or deceleration. It assumes the printer is always operating at the maximum feedrate,</p></li>
<li><p>The length of filament extruded. The feedrate is the speed for the move in (X,Y,Z,E), but Cura only looks at (X,Y,Z).</p></li>
<li><p>The time it takes to heat up the print bed/hotend or homing/autoleveling,</p></li>
<li><p>The effects of the printer slowing down if moves can not be read (from USB/SD-card) sufficiently fast (though this would be rather hard to include in any estimate).</p></li>
</ul>

<p>The accuracy of this estimate can be arbitrarily bad if the feedrate is set to some unrealistic value.</p>

<p>Newer versions of Cura use a much more advanced time estimate method, and it can be found in <a href="https://github.com/Ultimaker/CuraEngine/blob/master/src/timeEstimate.cpp" rel="noreferrer">timeEstimate.cpp</a>.  It is much more complicated, and actually takes jerk/acceleration/deceleration into account. It is much more accurate.</p>

<p>We know <em>exactly</em> how 3D (open source) 3D printer firmwares work, so estimating print time is as easy as simulating execution of the G-code by your given firmware. There is no reason you can't get a really good estimation (if you take into account all of the intricacies of your given firmware's acceleration/deceleration techniques) but writing the code for it is rather involved.</p>

CC BY-SA 3.0
2017-08-09T07:29:51.557Z
2017-08-09T07:29:51.557Z
Tom van der Zanden
<p>I am curious about the algorithm/principles behind the estimates that the slicing softwares provide. Is there a standard technique behind this and how accurate is it ?</p>

CC BY-SA 3.0
2017-08-09T12:58:47.790Z
And let's not forget the psychological part: the beginning of a print always seems to take forever, partly because there's little in the way of recognizable shapes.  The last 25% or so of the layers , not only is the shape quite visible, but typically these layers cover much less area than the base, so the time per layer does decrease.
Carl Witthoft
<slicing><g-code>
How is the print time of an object to be printed estimated?
GSH
# How is the print time of an object to be printed estimated?

(Asked by: username_0 on 2017-08-08)

I am curious about the algorithm/principles behind the estimates that the slicing softwares provide. Is there a standard technique behind this and how accurate is it ?

**Tags:** slicing, g-code

> **Comments:**
> **username_1**: And let's not forget the psychological part: the beginning of a print always seems to take forever, partly because there's little in the way of recognizable shapes.  The last 25% or so of the layers , not only is the shape quite visible, but typically these layers cover much less area than the base, so the time per layer does decrease.  

---

## 2 answers

### Answer by username_2 on 2017-08-09. Score: 1 | Accepted answer

Generally speaking, the typical algorithm takes into account the slicer's speed settings for specific features of the build, such as infill, perimeters, top/bottom layers, etc. The distance traveled by the nozzle at a specific speed for each feature is also part of the equations involved. There are some rather vague portions of the nozzle movement based on acceleration and other factors which makes the calculations less accurate.

> How accurate is it?

Not too accurate. My experience with three different slicers is that it's never been within better than ten percent. I believe the various combinations of features of a build are not going to be identical from one model to the next, preventing even a ballpark figure to be created from previous builds.

> **Comments:**
> **username_0**: Can you provide a reference where one could see how these calculations are made ? Like a piece of code or the algorithm itself.  
> **username_2**: Tom van der username_3's answer is a bit more convoluted than I can follow, not being a code person, but is a good start. I've found a number of web sites containing basic descriptions of calculations, including http://forums.reprap.org/read.php?2,647001 but all of them appear to be missing various factors. In most of the sites, the acceleration is ignored or approximated. As a result, the build times are approximations. I suppose if one were applying orbital dynamics mathematics to 3D printing, one could get more accurate results.  
> **username_1**: Unless you're dealing with multi-day prints, I'd say 10% is more than adequate accuracy.  

---

### Answer by username_3 on 2017-08-09. Score: 5

Much of the software used in 3D printing is open-source, and so are some slicers. Cura, for instance, does (or did, this source code is from an older branch) its print time estimation in [gcodeInterpreter.py](https://github.com/smorloc/Curation/blob/master/Cura/util/gcodeInterpreter.py).

The relevant portion of the source code is (simplified and with many lines removed for clarity):

```
    totalMoveTimeMinute = 0.0
    pos = util3d.Vector3()

    for line in gcodeFile:
        G = self.getCodeInt(line, 'G')
        if G is not None:
            if G == 0 or G == 1:    #Move
                x = self.getCodeFloat(line, 'X')
                y = self.getCodeFloat(line, 'Y')
                z = self.getCodeFloat(line, 'Z')
                e = self.getCodeFloat(line, 'E')
                f = self.getCodeFloat(line, 'F')
                oldPos = pos.copy()
                pos.x = x
                pos.y = y
                pos.z = z
                feedrate = f
                currentE = e

                totalMoveTimeMinute += (oldPos - pos).vsize() / feedRate

```

As you can see, (this version of) Cura simply:

* Loops over all the G-code instructions,
* Computes the length of each move (in X/Y/Z) and divides that by the feedrate to get the time that move will take,
* Sums this up over all the moves.

and does not take into account:

* Acceleration or deceleration. It assumes the printer is always operating at the maximum feedrate,
* The length of filament extruded. The feedrate is the speed for the move in (X,Y,Z,E), but Cura only looks at (X,Y,Z).
* The time it takes to heat up the print bed/hotend or homing/autoleveling,
* The effects of the printer slowing down if moves can not be read (from USB/SD-card) sufficiently fast (though this would be rather hard to include in any estimate).

The accuracy of this estimate can be arbitrarily bad if the feedrate is set to some unrealistic value.

Newer versions of Cura use a much more advanced time estimate method, and it can be found in [timeEstimate.cpp](https://github.com/Ultimaker/CuraEngine/blob/master/src/timeEstimate.cpp). It is much more complicated, and actually takes jerk/acceleration/deceleration into account. It is much more accurate.

We know *exactly* how 3D (open source) 3D printer firmwares work, so estimating print time is as easy as simulating execution of the G-code by your given firmware. There is no reason you can't get a really good estimation (if you take into account all of the intricacies of your given firmware's acceleration/deceleration techniques) but writing the code for it is rather involved.


---

