Print started 11:36 Local time (EDST)
S3D estimated 3 hours 29 minutes
Octoprint still thinking about it and has not provided an estimate
Norman check your email, sent you login info for my proxy so you can keep tabs on the print if you like.
Octoprint says 22 minuets of print time passed 3.5 hours left.
When I enter the credentials I get the message "Your connection to this site is not private"
Just say ok and go.. not https. no worries
When I click "Sign in" the credentials boxes then clear and nothing happens
sent you email norm passwd was wrong in the first mail
Trying another combination.
Opened the Queen in Cura 3 (64 bit) not 15.04.6 (the last supported version of Octaprint). This gave me the options to either save file to disk or print using Octaprint. I saved the gcode file to disk and was given the estimated time of 1:58.
Currently printing in Octoprint with an estimated time of 4 hours. Go figure.
If I open the Queen file with Cura 15.04.6 (32 bit) it tells me the estimated time is 3:58. Pretty much the same as Octoprint. I guess my next test is to open the next piece in Cura 3 (64 bit) and "Print with Octaprint" and then finally print with my PC via USB. These I'll leave till tomorrow though. It's nearly dinner time here (UK) and I've been sitting in front of my PC for about 10 hours.
If you like the Cura-provided estimate then you'd want to go with that. This is actually embedded in the GCODE after the last layer has been included.
Divide that by 60 and you have the time in minutes: 5:26.
Believe it or not, this is a very small part and it takes about six minutes in my own rough estimate but perhaps 30 seconds of that is warming up the extruder and doing the G29 autolevelling routine.
I guess I'll create something that will just trust Cura for the time estimate. The other side of the coin then is progression. What constitutes a unit of progression?
A discrete layer is the trivial one but for parts like a pyramid that doesn't work very well. This is typical of the quality of progress meters which you see for Microsoft installs, for example.
Current offset into the GCODE file (byte 300 of a file 600 bytes in size) would tell you that you're exactly 50% done. You'd then multiply (1.0 - 0.5) times the earlier time estimate and this is the new time-to-complete statistic. This is the approach that I have suggested before and which I'll probably implement in a plugin.
Current extrusion versus total expected would likely be the most accurate of all. Given that there are now absolute and relative extrusion modes possible this makes things a little too complicated. Note that you'd have to keep track of zeroing of the extruder throughout the file. And what about dual extrusion? Probably too much going on there to make this version fun.
Forgot to look when the King finished.. according to estimate should have been 3pm and when I realized I had head it finish and forgot to look it was 4pm so I am guessing maybe 15-30 minutes longer
Here is the time laps Time Laps of King
Thanks Doug. I started the Queen at much the same time as you and monitored both yours and mine. Yours finished in around 4 hours and my Queen in 4:30. A lot better than the estimate for the King. I'm not satisfied with the quality so I'm trying again, this time using Cura 3 without support and with a layer height of 0.1 rather than 0.15. I'll try both saving the gcode and loading into Octoprint and also printing direct from my PC.
Cura has given an estimate of 2:58 and when loaded into Octoprint it shows 2.5 hours. It still looks like a very optimistic estimate.
Edit:- the 2.5 hours estimate turned out to be 3:24 actual
can you post a picture of yours, would be interested to see the kink via cura vs S3D.. I did print at 35mms which is a little faster than what I use for miniatures..
Looks good, what was the issue you didn't like.
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).
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.
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.