Print Time Left: Calculating... about 60 percent into a print

[yannick12]

What were you doing?

I was printing a print. The issue I'm going to raise always happens.

What did you expect to happen?

I was expecting to see the "Approx total print time" and "Print time left" fields populated in the web interface.

What happened instead?

90 minutes into my 2.5 hour print, Approx Total Print Time is "-" and Print Time Left is "Calculating...". On the other hand I sliced the print with Cura before sending the gcode to OctoPi and Cura told me that the print was 2h35; furthermore Octoprint in the "GCode Viewer" tab seems to have an estimate for the print time of every single layer of my print, other than the very top layer, which seems to be empty and which has a layer height of -1 and a print time of "-".

Branch & Commit or Version of OctoPrint

1.2.8 (Master)

Printer model & used firmware incl. version

Printrbot Simple Metal

Browser and Version of Browser, Operating System running Browser

Any (I'm using Firefox 44.0 on Ubuntu)

Screenshot(s) showing the problem:

I have read the FAQ.

I think that the issue might be this. My cura is generating gcode which ends like this:

[first 65 layers and most of 66th layer omitted]
...
G0 F4200 X13.420 Y129.102
G1 F1800 X14.082 Y129.764 E8727.62161
;LAYER:67
G1 F2400 E8726.62161
G0 F4200 X13.840 Y84.034 Z13.566
;TYPE:WALL-INNER
G1 F2400 E8727.62161
G1 F1800 X12.664 Y84.034 E8727.66
...
[most of 67th layer omitted]
...
G0 F4200 X12.884 Y129.384
G1 F1800 X13.168 Y129.101 E8763.59280
;LAYER:68
G1 F2400 E8762.59280
G0 F4200 X13.465 Y84.034 Z13.764
;TYPE:WALL-INNER
G1 F2400 E8763.59280
G1 F1800 X13.040 Y84.034 E8763.60680
G1 X13.146 Y83.456 E8763.62614
G1 X13.546 Y82.173 E8763.67040
...
[most of 68th layer omitted]
...
G1 X42.440 Y138.040 E8785.72844
G1 X42.837 Y138.155 E8785.74205
M107
G1 F2400 E8784.74205
G0 F4200 X42.837 Y138.155 Z18.700
;End GCode
M104 S0 ;extruder heater off
...

That last G0 command moves Z and so perhaps is creating another layer with essntially nothing happening in it. Octoprint then perhaps chokes when computing the amount of time need to print this 69th layer.

The screenshot shows Octoprint trying to deal with the 69th layer. All the other layers are computed fine, with accurate-looking times. I am guessing that this one glitch on the non-existent 69th layer causes the total calculation to fail. It's hardly a deal-breaker but for some reason it occurs most of the time for me (Cura 15.04.4 on Ubuntu).

[yannick12]

I'm wrong. The issue is not that we have a bogus layer. I'm now printing something else and every layer has a time attached to it, but the total print time is still not being displayed.

This is only a very minor irritation because in the process of creating the gcode cura has already given me a good estimate of how long the print will take, but I find it surpising that octoprint isn't at least giving me an estimate. My gcode does not have time estimates in it -- is this the issue? I've noticed that some default "start gcode" code in cura has lines like

;Print time: {print_time}

so you get estimated print times in the comments. But I'd be surprised if this is what octoprint is looking for because it seems to know print times for all the layers.

[yannick12]

About half way through this print, the time left has suddenly sprung into action. Is this expected behaviour? Total time still down as "-", and total time for each layer has been known essentially since the print began.

[foosel]

Is this expected behaviour?

Yes. There's a lengthy post of mine on the mailing list that explains why figuring out the print time that is left is way more complicated than you'd intuitively think.

The print time approximation you don't have there is something that is calculated in the background when OctoPrint is not printing, since it's a very CPU intense process that necessitates parsing the full file on the server in order to analyse it and persist the data. CPU intense -> could disrupt the print job, so it's not done if you upload something and immediately click print.

The "Print Time Left" has multiple sources, one being the approximation - if available only of course - and the other being an attempt at linear interpolation of the non-linear process that is printing without showing completely off-the-chart values ("Print Time Left: 30 days") to the user in the beginning. Depending on the model it can take longer or shorter until the run-time estimate stabilizes, so it can happen that you see "Calculating..." for a very long time on first-time-prints depending on how the model is structured (wide vs small layer areas etc).

Additionally, the GCODE viewer runs completely within your browser and does a GCODE analysis on its own to be able to render what is being printer. Since it has to do that anyhow, it also prints out some stats about the layer. This however is not propagated back to the backend. MIght be interesting to look into that to help with analysis, but would couple components (the gcode viewer and the backend) which shouldn't actually be very tightly coupled, so that makes things tricky.

In any case, what you are seeing is sadly an example for when the current solution goes bad, but - as written in the linked mailing list post - it's as good as it gets right now.

[yannick12]

Aah I see! If the Gcode viewer is running within my browser then I have a feature request: why not give us an "approximate total time" estimate which is simply the sum of the estimates of the times of the layer printing plus the time it took for the bed/nozzle to reach the correct temp? This could also be done within the browser. In particular whilst I now understand much more about how terrifically difficult it is to guess time taken, my suggestion (rough estimate calculated by browser based on estimates for each layer, as computed by the browser, and labelled with "estimate" to make it clear that it's just a guess) would perhaps better than what we have now, contrary to the claim in your last sentence ;-)

Many thanks for this quick and informative response. I am extremely impressed with Octoprint: the fact that it would not tell me a total time when cura would happily give me an estimate is my only issue with the entire set-up, and now (a) I can understand the problems and (b) I will just continue looking at cura output for this information. You can close this if you are not interested in letting the browser give us an estimate -- but if you do implement this it will save me from the pain of adding up the estimated time for each layer in my head, which I did do once :-)

[nophead]

Yes the warmup time and the slow first layer always send the estimate to
tens of hours and then it takes the rest of the print for it to come down.
Would it be possible to save the time and file position after the first
layer and then estimate the rest of the layers not including the first and
add that to the first layer time?

On 30 January 2016 at 18:45, yannick12 notifications@github.com wrote:

Aah I see! If the Gcode viewer is running within my browser then I have a
feature request: why not give us an "approximate total time" estimate which
is simply the sum of the estimates of the times of the layer printing plus
the time it took for the bed/nozzle to reach the correct temp? This could
also be done within the browser. In particular whilst I now understand how
terrifically difficult it is to guess time taken, my suggestion (rough
estimate calculated by browser based on estimates for each layer) would
perhaps better than what we have now, contrary to your claim ;-)

Many thanks for this quick and informative response. I am extremely
impressed with Octoprint: the fact that it would not tell me a time when
cura would happily give me an estimate is my only issue with the entire
set-up, and now (a) I can understand the problems and (b) I will just
continue looking at cura output for this information. You can close this if
you are not interested in letting the browser give us an estimate -- but if
you do implement this it will save me from the pain of adding up the
estimated time for each layer in my head, which I did do once :-)

—
Reply to this email directly or view it on GitHub
#1204 (comment).

[yannick12]

My point is that after the warm-up time we seem to have an estimate already, at least if my understanding is correct (we can add the estimated layer times together), and I'm just suggesting that this is displayed (within the gcode tab if you like) with a clear indication that it is only an estimate.

[foosel]

Would it be possible to save the time and file position after the first layer

There's no way for OctoPrint to reliably in each and every case it might encounter determine the first layer. What to do for spiralized prints? What to do for prints from SD where there isn't even a way to access the printed GCODE? What to do for plate setups where there are multiple first layers? As soon as you have exceptions from the rule, stuff starts to become unmaintainably complicated as wrong assumptions lead to even more issues along the road, which lead to more exceptions, which... you get the picture.

I'm just suggesting that this is displayed (within the gcode tab if you like)

Will be in 1.2.9, see 5955d3d

[nophead]

I suppose it is a direct consequence of the what we agreed before: that RepRap incorrectly partitions the functionality between slicer, host and firmware. My own host just gets the geometry from the slicer and does all the machine control including path speeds and acceleration, retraction and warmup. My firmware is a simple slave that only does what it is told to do. Consequently my host can know exactly how long a print will take in all circumstances.

Comms bandwidth is such that I don't need local storage on the controller, it always streams from the host, which can be an RPi integral to the machine of course. So there is only one mode of operation. I just need to find a way to link it to OctoPrint to give it a web front end.

[yannick12]

Many thanks for this Gina. My OctoPi updated over the last couple of days and now I see the estimated total time in the gcode tab. I am in the middle of a print that cura says will be just over 8 hours and octoprint says the same, so this is a great start.