I've always noticed the print times in Octoprint seem to be about half-right. Meaning, it usually takes about twice as long as estimated.
It's not my slow pi. It might be my slow printer. But I can tell the printer is staying fed all the time since the speed doesn't drop between lines.
I shrug and get on with life. When the time turns out to be more accurate than usual, it's like I got a little part of my day back.
I'm also quite curious about the estimated print time, because for my first use it is double what the slicer says.
New to OctoPrint, Raspberry Pi etc. and still a newbie at 3D printing.
Have printed a dozen things sliced with Cura3D on my Creality Ender 3D, the print time would never seem to be off, maybe a couple minutes for a multi-hour but still simple item (on finer resolution and average print speed).
Just created an updated version of an item, which takes a good 4 - 5 hours ...
Cura3D:
5 hour print
Uploaded the gcode via OctoPrint to the Raspberry Pi 3B and let it start printing.
An hour into the print, I check in via the web interface: 9 hours remaining?
So essentially,
Octoprint:
10 hour print
Quite puzzling.
I'm currently also not seeing any progress indication on the progress bar on the printer. It is printing the base, the slowest part of the item, but still ...
Guess I'll know in a few hours and update.
Since v1.3.9 of OctoPrint, foosel's opened up some things in the API so that others can write plugins which directly address this. Visit the plugin page, hit the more link at the bottom and see what's available.
Actual print time was ~ 5 hrs 17 mins.
I suggest to watch
The challenges of live print time estimation (which you had going there, no analysis result available at start of print) are explained there starting at the 44min mark.
Side question, where did you get that set? Can you share?
Thanks!
Jonathan
Is octoprint setup to take a timelapse? This could slow the print time somewhat if the print stops to take a photo every layer.
Look for that magnifying glass icon in the upper-right corner of this page and enter the word timelapse. Many topics exist for this question.
I think you could greatly improve the accuracy of the linear interpolation by ignoring the first N = [50,100, whatever...] lines, especially only calculate your bytes/second once the bed and extruder are heated. In my case heating up takes 15mins (sadly) and untill then only 50 bytes have been read. So from that my 4.2KB/4h print would take 21 hours. Ignoring that would greatly increase the accuracy as you're moving the lower/left point of your interpolation.
Please excuse my horribly faked onenote graph...
I'm actually ignoring the linear interpolation completely until it's stabilized within a rolling window of I think 250 measurements. Would need to check the exact code. That filters out more than the first 100 lines. Heating times are substracted and shouldn't be taken account anyhow. The problem is huge flat slow base layers.
If you want to take a look:
On a related note:
My own printer (Robo C2) arrived with a cheap 19V laptop-style power brick to power both the printer and the Pi 3B inside. They'd hidden the undervoltage warnings in a config.txt attribute so that I wouldn't know that the Pi wasn't getting enough power; so I dedicated a separate power adapter for that. I then researched enough to find out that the Robo controller board and printer would work just fine on a beefier 24V power brick pushing more current so I replace that.
My heat-up times immediately changed for the good. It will come up to 190C in a few seconds now.
Would it be possible to use how much material is extruded + the time the printer takes to print part of the plastic? It seems that it estimates it taking less time for detail work, but when it is doing infill or raft parts, it gives a much worse estimation. This approach would worry less about the length of the instructions and more about how much plastic it has to go through. Just a thought 
It seems to me that when you include the warmup time for HOTEND and BED, time estimates go crazy. I think warmup period should therefor be EXCLUDED (and perhaps added back in as a fixed time of its own) then it would be much more accurate. Only start estimating time once printhead begins moving (and maybe not even calculate for the first 30 seconds)
perhaps the first step is MORE DATA. Allow the export of time in a spreadsheet format (comma separated) with
TIME | Print time estimate remaining
perform every x seconds or at every new command. These can be graphed and it may be easier to understand where time estimates are going wrong.
We can then run standard deviation at each moment to see where the error is significant enough to be "BAD". then trace down which types of functions create inaccuracies... then develop "fudge factors" to try improving these estimates...
all calculations done OFFLINE, raspberry only outputs simple file....
perhaps the slicer can be of assistance, if comments are placed which state certain settings:
bottom layers, infill %, etc. then raspberry pi and octoprint has more info to calculate more accurately....
