ETE Estmiation improvement
Hi there!
I love the repetier host, its an awesome tool! one tiny thing that is a bit annoying is the ETE (in german, i guess its called ETA in english) estmiation how long the print will take.
I know that i can set a factor to calibrate this to a more realistic number, but that still doesnt seem to fit. it would be very awesome to have a constant reevaluation of the remaining time, like if i start a print with estimated 8 hours, and for some reason (as most of the time) the printer is slower than expected, that the time gets updated during the print, currently the estimation stays, but the seconds pass with double or half the speed.
Maybe it also would be cool to store the estimated and actual time of a print in the context of the printer, so that with every print, the base factor could be slightly adapted automatically to improve the base estimation. And one last thing, it would be awesome if somewhere the starting time would be shown.
Would be very cool to see these things in the repetier host (dk about the repetier server, but i could imagin that also the repetier server acts the same here).
Greetings from Austria,
Georg
I love the repetier host, its an awesome tool! one tiny thing that is a bit annoying is the ETE (in german, i guess its called ETA in english) estmiation how long the print will take.
I know that i can set a factor to calibrate this to a more realistic number, but that still doesnt seem to fit. it would be very awesome to have a constant reevaluation of the remaining time, like if i start a print with estimated 8 hours, and for some reason (as most of the time) the printer is slower than expected, that the time gets updated during the print, currently the estimation stays, but the seconds pass with double or half the speed.
Maybe it also would be cool to store the estimated and actual time of a print in the context of the printer, so that with every print, the base factor could be slightly adapted automatically to improve the base estimation. And one last thing, it would be awesome if somewhere the starting time would be shown.
Would be very cool to see these things in the repetier host (dk about the repetier server, but i could imagin that also the repetier server acts the same here).
Greetings from Austria,
Georg
Comments
For the unknowing print time it might be an idea to scale after 1 hour maybe so start turbulence has less effect. We will do some math and test.
i really dont know much about the printing times deviations, but i really could imagin that if you print 10 different models and compare the ETA to the effective time, a "general" factor should appear which at least points into a good direction. Additionally, well thats of course way more work, i could imagin that a gcode model consists of different "printing types", with printing types i mean something like "short movements with traveling afterwards" or "long continuous movements", which might have their own factor. now that im writing it it sounds like a lot of work, and would maybe be an interesting topic for machine learning (neural networks). Would it be possible to add a logging which says how long which gcode command took?
It is not possible to see how long commands take. In log you see timestamps so you can see when you get a response that they got executed, but e.g. moves will be queued and executed later so delay until ok is based on time of a previous move to empty a new place in buffer and does not depend on the execution time it self.
btw, thanks for your fast responses and that you take your time to read everything! Additionally i would have some toughts / ideas for improvement about the server UI, but i dont want to be annoying, is it ok if i just drop it as a "bug report"? (even though they are not real bugs)
Command-Ok in general is correct - at least in ping pong mode. But as I said moves get buffered and then a new move might have to wait for the oldest move in buffer to get finished. So during print the times have nothing to do with execution time.