I have been busy printing now that my Printrbot Simple Metal is back to working condition. I notice that Cura and Octoprint both have estimation of print time that is completely off-whack. Prints that take 1 hour is estimated as 5 on OctoPrint.
Is this an issue that we can fix by machine learning? Given the model and the settings as the input vector, create a predictor of the time required for printing. Surely something is better than the current state.
P.S. Makerbot software is also a crap-shoot when it comes to estimation so this might be much harder problem than I originally thought.
yeah it can seem to be exponentially off. I just got my i3 running and have very conservative accel/decel firmware settings so Reptierhost is waaaay off. I know you can add a % fudge factor in the printer settings but it still feels like a roll of the dice either way.
@Dat_Chu @foosel and I have both worked on this before, and it really is a difficult problem. The primary reason is that the part that has the most unknown time requirements happens during the time where we have the least information to go from, which is the beginning of the print. So because one of the first few commands takes a while to execute (heating), it assumes they all do.
The problem has been mitigated a bit in OctoPrint’s devel branch, which also tries to take available estimates from the slicer and average run times from previous prints into account and doesn’t display the print time at all until it becomes somewhat stable (= doesn’t change quickly which is often the case right at the beginning). The heat up times are also substracted, as are pause times, but the first layers of a print still behave totally differently than the rest, they are usually slower, same goes for the last couple of layers. It’s just no linear procedure. And even if you know the gcode by heart, there are still acceleration settings and firmware implementation specifics that make any estimation go off.
Given that we have variables which cannot be calculated, I think this problem can be solved with some advanced statistics or big data. If we have access to a big set of gcode + machine parameters => real time elapsed, I think this is within the realm of solvable problem with big data. Maybe OctoPi can start having an opt-in program for statistics about the prints to be collected to improve the estimation feature?
Every printer is different. So the statistics wouldn’t be a lot of help. If I configure my printer with acceleration X and firmware version Y and you configure yours with acceleration A and firmware version B (even if it’s the exact same model and firmware variant) we’ll have deviations in behaviour.
It just doesn’t make a lot of sense to pour so much energy into something like getting an accurate estimation to the second if the usefulness of that basically boils down to “can I still get a coffee before the print is done or not”. Which is why OctoPrint in devel now shows the Print Time Left in a fuzzy way and tries not to be mega-accurate but rather reliable - meaning, if you get shown a value for “Print Time Left”, it will make as much sense based on the current live data as it can (so no more “Print Time Left: 42 days” when it actually will be at “15 minutes” about 3 minutes later).
I agree it’s probably too much trouble, but I could report on estimated and actual time for certain models and perhaps octoprint could use a printer profile to allow users to identify the printer they are using… Then it could apply a simple equation to adjust the estimated time more accurately. Printer profiles would make other settings easier too like build size
