Skip to content

octoprint.printer.estimation#

PrintTimeEstimator(job_type) #

Estimator implementation.

Subclass this and register via the octoprint.printer.estimation.factory hook to provide your own implementation.

estimate(progress, printTime, cleanedPrintTime, statisticalTotalPrintTime, statisticalTotalPrintTimeType) #

Tries to estimate the print time left for the print job

This is somewhat horrible since accurate print time estimation is pretty much impossible to achieve, considering that we basically have only two data points (current progress in file and time needed for that so far - former prints or a file analysis might not have happened or simply be completely impossible e.g. if the file is stored on the printer's SD card) and hence can only do a linear estimation of a completely non-linear process. That's a recipe for inaccurate predictions right there. Yay.

Anyhow, here's how this implementation works. This method gets the current progress in the printed file (percentage based on bytes read vs total bytes), the print time that elapsed, the same print time with the heat up times subtracted (if possible) and if available also some statistical total print time (former prints or a result from the GCODE analysis).

  1. First get an "intelligent" estimate based on the :class:~octoprint.printer.estimation.TimeEstimationHelper. That thing tries to detect if the estimation based on our progress and time needed for that becomes stable over time through a rolling window and only returns a result once that appears to be the case.
  2. If we have any statistical data (former prints or a result from the GCODE analysis) but no intelligent estimate yet, we'll use that for the next step. Otherwise, up to a certain percentage in the print we do a percentage based weighing of the statistical data and the intelligent estimate - the closer to the beginning of the print, the more precedence for the statistical data, the closer to the cut off point, the more precedence for the intelligent estimate. This is our preliminary total print time.
  3. If the total print time is set, we do a sanity check for it. Based on the total print time estimate and the time we already spent printing, we calculate at what percentage we SHOULD be and compare that to the percentage at which we actually ARE. If it's too far off, our total can't be trusted and we fall back on the dumb estimate. Same if the time we spent printing is already higher than our total estimate.
  4. If we do NOT have a total print time estimate yet but we've been printing for longer than a configured amount of minutes or are further in the file than a configured percentage, we also use the dumb estimate for now.

Yes, all this still produces horribly inaccurate results. But we have to do this live during the print and hence can't produce to much computational overhead, we do not have any insight into the firmware implementation with regards to planner setup and acceleration settings, we might not even have access to the printed file's contents and such we need to find something that works "mostly" all of the time without costing too many resources. Feel free to propose a better solution within the above limitations (and I mean that, this solution here makes me unhappy).

Parameters:

  • progress (float or None) –

    Current percentage in the printed file

  • printTime (float or None) –

    Print time elapsed so far

  • cleanedPrintTime (float or None) –

    Print time elapsed minus the time needed for getting up to temperature (if detectable).

  • statisticalTotalPrintTime (float or None) –

    Total print time of past prints against same printer profile, or estimated total print time from GCODE analysis.

  • statisticalTotalPrintTimeType (str or None) –

    Type of statistical print time, either "average" (total time of former prints) or "analysis"

Returns:

  • –

    (2-tuple) estimated print time left or None if not proper estimate could be made at all, origin of estimation