Print time estimate

[robteifi]

What were you doing?

Printing a fairly simple model

What did you expect to happen?

I expected the print time estimate to be at most 90 minutes

What happened instead?

Print time estimate started at 2 days, and started dropping after the heaters had reached temperature and printing actually started. Should probably reset the time at the point the printing actually starts to give a more accurate result.

Branch & Commit or Version of OctoPrint

1.2.15.post1+gafdb98a
[Can be found in the lower left corner of the web interface.]

Printer model & used firmware incl. version

Flashforge Creator Pro 2015 version (unsure of firmware verson)

Browser and Version of Browser, Operating System running Browser

Not relevant

Link to octoprint.log

https://gist.github.com/robteifi/fe6125f36becdc8052ed9a5f43c98d27

Link to contents of terminal tab or serial.log

Link to contents of Javascript console in the browser

Screenshot(s) showing the problem:

I have read the FAQ.

[GitIssueBot]

Hi @robteifi,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Please take a look at the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2016-08-13 16:00) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[robteifi]

Interestingly, a subsequent print that should take about 4 hours had an initial estimate of 9 hours. After the bed reached temperature and the hot-end heater was switched on, this shot up to 8 days, rapidly dropping to 2 days within the first minute or so of actual printing.

[robteifi]

And after about 35 minutes of printing the estimate has dropped to 6 hours

[LunNova]

Estimation:

What is the estimate calculation source (mouse over the colored circle next to the "print time left") when you get the wrong estimates?

[markwal]

I wonder if it is because OctoPrint doesn't know when you're waiting for temperature for some reason relating to my plugin. I don't see this exterme of a result myself, but perhaps you and I are using different start gcode. Could you post a link to a sample gcode file that shows the problem?

[robteifi]

@nallar It starts with "Based on a linear approximation" (I think, it just changed from dark red to green), and is not "Based on the calculated estimate (best accuracy).

@markwal I am using your GPX plugin. My bed temp is 105C and hotend temp of 230C. Let me see what I can find to upload...

18650 chamber - lid-v2.gcode.zip

BTW Gcode was generated by Simplify3D

[ntoff]

I saw it all the time with printrun, it estimates based on how long each layer takes + how much is left so if the printer isn't moving for the time it takes to heat up, it thinks that first layer is going awfully slow so the time estimate goes into the days but once it starts printing the estimate comes down and starts to become more accurate.

[foosel]

OctoPrint does in fact take the heatup time into account however. My guess is there's rather something going on here in combination with the GPX plugin, like @markwal already suggested.

Do you have "detect external heatup" disabled by any chance? That might create such issues potentially.

[robteifi]

That's the setting under Features? It's not disabled (ie the check box
isn't checked)

On 1 August 2016 at 10:01, Gina Häußge notifications@github.com wrote:

OctoPrint does in fact take the heatup time into account however. My
guess is there's rather something going on here in combination with the GPX
plugin, like @markwal https://github.com/markwal already suggested.

Do you have "detect external heatup" disabled by any chance? That might
create such issues potentially.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1428 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEPXqEHbaoPRgANw5hVm4PZ3WbFZrkClks5qbbXggaJpZM4JY1ZT
.

Shireglobe Computers Limited

[bolsoncerrado]

I do think its way off even for a estimation....

http://i.imgur.com/mPjOuG3.png

[jpvonhemel]

I have occasionally seen this same issue and I don't use the GPX plugin. I am also seeing a nil value for Estimated Total Print Time under Model Info in the GCode Viewer Tab.

This is my first post here, so if I am wrong posting this here, please let me know where to go.

[kylek29]

I've noticed this too recently. I did an update via the browser prompt, don't recall it happening before then.

Before it was fairly accurate. Now it's estimating at around 10+ hours for a 1 hour print. It corrects itself about a quarter way through or so (haven't watched it intensely).

As some have suggested, I'll play with the GPX and check a few things. I have a MakerBot clone (Qidi Tech I, dual extruder).

[foosel]

FWIW, I just pushed a commit that brings back the old behaviour of not displaying the linear ("red bubble") estimate unless it's stabilized somewhat OR a specified percentage of the print or elapsed time has been reached.

That doesn't make a linear approximation of a completely non linear process magically better, but it simply disables displaying the wonky initial values again and shows "Still stabilizing..." until then (formerly "Calculating...").

To make one thing absolutely clear: If you want better estimates, you need to give OctoPrint at least the time it needs to do a basic analysis of the GCODE file you uploaded. If you upload something and immediately click print, OctoPrint has NOTHING to base its estimate on other than "I now have printed x percent of that file and needed y minutes for that" - trying to guess at the total print time based on that is bound to not work especially at the (slow) first couple of layers, and depending on the model it may even not provide any meaningful accuracy at all over the duration of the full print. Since that's a topic that keeps coming up again and again and again, I'll try to find the time to add an FAQ entry about this, maybe even a blog post with some diagrams to explain why a simple linear estimate can't be accurate (it's simply technically impossible) and why accuracy is especially horrible the earlier in the print you are, and also link to the segment from the recent Patreon hangout I also covered that subject in, as soon as I've gotten around to publish that video.

tldr; be patient enough to wait until "Approx. Total Print Time" shows a value and your estimates will magically improve because OctoPrint can then do better than providing an estimate of a complex process based on nothing more than two data points. Stop clicking on "Print" directly after an upload if you want better estimates right from the very beginning.

@markwal I'm not sure if your plugin is at fault here or if people just got irritated with the early display of the wonky linear estimate here. Considering that the complaints are about "red bubble" estimates as far as I can tell, I actually think this can be closed ones the early display is disabled again / 1.2.16 or 1.3.0 is released with the above commit.

[LunNova]

If you want better estimates, you need to give OctoPrint at least the time it needs to do a basic analysis of the GCODE file you uploaded.

Would it be possible to run analysis during printing if a heatup is detected?

During heatup, presumably, any performance impact from running the analysis will not cause problems.

I usually set the bed temperature, upload a file, and then wait for the approximate time to show up before clicking print. It would be more convenient if it could automatically do the analysis while the bed is being heated.

[kylek29]

Obviously estimating the time is difficult. I have noticed that a few of the slicers put their build-time estimates in the gcode file. Possibly a future feature is to have it look into the gcode for these for a starting point estimate? I find them to be fairly accurate estimates.

For example, Simplify3d puts it at the bottom under "Build Summary" - "Build Time".

[robteifi]

Having just watched the recent hangout, it's clear that this is a really tricky problem. I'll try not to cause your eye to twitch again :)

[foosel]

@markwal You still got this assigned to yourself - are you looking into something here or can it be closed?

[markwal]

If there is a bug here, it's in my plug in. I'll track over there.