I was wondering why 'uploading to sd' doesn't show "Print Time Left" estimate. Progress is shown
nicely from the start. It turns out that it shows time left but it needs 5 minutes of upload working to get first estimate printed. Why so long?
What did you already try to solve it?
Looked what it does. It uses 'linear' for 5 minutes and then 'estimate' kicks in. If I patch TimeEstimationHelper.is_stable() to always return True I get sane estimate (about 25 min for 3.5MB file which is reasonable for 115.2k connection and g-code overhead) immediately from start of upload to sd card.
So something could be improved for streaming but what exactly to make estimators consider stable state earlier, even from start of sd card upload?
A print from SD card of the printer is not intended to send information via USB to a host or something else. Just to an attached LCD.
You could manage this by using M118 instead of M117. But the slicer has to support that feature.
Th longer the file, the more lines the PrintTimeEstimator as to parse to calculate the time.
The speed of the USB really don't count in that much in a process that is as comparatively slow as 3D printing.
This is no overhead. This is printing information. No g-code - no print.
What also slows things down is the constant use of an activated debug mode.
The octoprint.log is 62819 lines with and 15997 without debug info. That is almost a quarter.
The debug feature is for plugin developers to get their plugins running and maintaining.
(and prusa printers, for example, send printing progress status to host as custom response to M73 ... but as I said - it's not about printing from sd, so this is offtopic)
Not true. It can estimate purely on size and time progression. And it does. Just delays showing that estimation a lot thinking it doesn't have timing data with good quality (that is_stable() being False).
That sentence was about octoprint PrintTimeEstimator doing estimates correctly from the start and printing it when is_stable() was forced to return True. is_stable() being False prevents that data from being used and shown as "Print time left".
Also there is overhead. Uploading to sd is sending g-codes line by line, with printer firmware ACKing each line. Look in serial.log to see. Anyway that is not important for the problem from first post.
No. In reality PrintTimeEstimator accuracy doesn't depend on debug slowing it down.