Sorry Doug I thought you meant the one I reprinted at a line height of 0.1. I since reprinted the King at 0.1 and I'm pleased with the results. Here's all 4. Don't know whether my phone will have picked out the surface detail but the left hand one of each is the finer version.
OK, last experiment was to print the Bishop twice, once from within Cura v3 at 0.1 line height with no support the other time from the gcode file exported from Cura but printed in OctoPrint. This should be comparing like with like except that OctoLapse was running and may have slightly slowed the OctoPrint process.
Cura v3 - Estimated 2:09 - Actual 2:34 that included about 6 minutes of bed heating
OctoPrint - Estimated 2:00 - Actual 3:05 after pre-heating nozzle and bed in OctoPrint
No appreciable difference in final quality.
For testing purposes, you may want to print one of these using Cura's Settings -> Special Modes -> Spiralize Outer Contour setting. It might clean up those little bumps on the surface of each right-side version (noting that you changed the quality on those).
The versions on the right are using the original "Low Quality" setting those on the left are using "Fine". I'm happy with the outcome and there is an even finer setting available. I have used the spiralise setting with a vase and, you're right, it did look great. Here's the Rook in "Fine" (0.1 line height).
!
That looks fine (pun intended).
1 Like
Hello all! I am Betto from Argentina.
I signed up to the forum to reply on this topic as I also noticed a wild difference on the estimate printing time.
Yesterday I printed a knob for my Prusa i3 Hephestos, same stl sliced in Cura 3.4 64bits running in windows 10.
First print was using coarse quality(.4mm height) at 60 mm/s, at 210c for the hotend and 60c the print bed.
I used PLA. ETA in Cura was 15 min. I send it to octoprint from cura(via plugin) and it took 40min to finish the print. I have octoprint setup in a raspberry pi 1 model B.
Next print was on .3mm height, at 40mm/s, same temps and filament. ETA in cura was 27min. It took 33min to finish printing. But this time I saved the gcode in an sdcard and printed directly from the printer with the sdcard.
What could be the issue or explanation of why it took more time to print with octoprint?
I haven't tried with the laptop hooked up.
I will be testing another stl with all same settings, with octoprint, sdcard and laptop.
Thank you!
Depending on the model, your old Pi might simply not be able to keep up sending the lines fast enough. Try updating to a Pi3.
1 Like
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:
1 Like
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)