Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Print time estimate #1428

Closed
robteifi opened this issue Jul 30, 2016 · 18 comments

Comments

Projects
None yet
9 participants
@robteifi
Copy link

commented Jul 30, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 30, 2016

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

This comment has been minimized.

Copy link
Author

commented Jul 30, 2016

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

This comment has been minimized.

Copy link
Author

commented Jul 30, 2016

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

@nallar

This comment has been minimized.

Copy link

commented Jul 30, 2016

Estimation:

xkcd 612

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

@markwal

This comment has been minimized.

Copy link
Collaborator

commented Jul 30, 2016

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

This comment has been minimized.

Copy link
Author

commented Jul 30, 2016

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 1, 2016

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

This comment has been minimized.

Copy link
Owner

commented Aug 1, 2016

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

This comment has been minimized.

Copy link
Author

commented Aug 1, 2016

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

This comment has been minimized.

Copy link

commented Aug 3, 2016

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

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

@markwal markwal self-assigned this Aug 3, 2016

@jpvonhemel

This comment has been minimized.

Copy link

commented Aug 10, 2016

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.

screen shot 2016-08-09 at 8 26 04 pm

@kylek29

This comment has been minimized.

Copy link

commented Aug 10, 2016

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 added a commit that referenced this issue Aug 15, 2016

Fix minute comparison for dumb estimate fallback
Probably solves the core reason that caused #1428 to be
reported in the first place, totally inaccurate early linear
approximations (when nothing better is available) making
it to the user.

It should now display "Calcuting..." until the approximation
stabilizes OR the configured max percentage or max time without
an estimate are reached.
@foosel

This comment has been minimized.

Copy link
Owner

commented Aug 15, 2016

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.

@nallar

This comment has been minimized.

Copy link

commented Aug 15, 2016

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

This comment has been minimized.

Copy link

commented Aug 16, 2016

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

This comment has been minimized.

Copy link
Author

commented Aug 16, 2016

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

This comment has been minimized.

Copy link
Owner

commented Nov 26, 2016

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

@markwal

This comment has been minimized.

Copy link
Collaborator

commented Nov 26, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.