ETE Estmiation improvement

Svhorsch

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

Repetier

The main problem here is that the error is not linear and much depends on print settings. In the beginning the heating of bed and extruder cause the most linear offset especially in host. In server it is better tweakable to adjust heating time and differences for acceleration reduction (which is ignored in host but not in server). In next server release 1.2.1 we will do a similar solution for the case the model was already printed - we then adjust a factor to the last print time.

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.

Svhorsch

Cool, thanks!

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?

Repetier

Actually host has already a multiplier to adjust to predicted times - you just need to set it correctly based on time deviation experience. What I talked about is more a during print optimization on top. This will be bad at start and improve towards the end, as we need to measure error based on past print.

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.

Svhorsch

Then maybe i got the protocol wrong, what happens in my mind is like the COMMAND - OK transfer, like if i submit 10 commands, i will get 10 OK's at that time when the printer either starts executing it or finished execute it. that would then give the possibility to track the time between to OK's and map it to the given command. But maybe im completely wrong, in that case i really apology.

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)

Repetier

You can also send me just a PM about ideas.

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.

genn

Hi, I just upgraded from reperier host 2.1.6 to 2.2.4

My printer is almost finishing to print a vase (may be 10-15 minutes to end) and there is some problem with ETA:

This is the ETA table I get, based on print speed setting

SPEED ETA

100 10:34;42

186 00:37:22

270 20:36:48

Can someone explain this cumbersome behavior of 2.2.4 ?

Repetier

There is a new estimate routine that tries to adjust based on past error. Using speed multuplier seems to break that computation.

genn

Thank you for the prompt ansewer

Ok, I would imagine that will be fixed in future releases, right?

However, please note, my table shows that even at nominal speed settings (100 ) the ETA is wrong

Repetier

Yes, fix is planned. Short ETA have always a big uncertainty since a hot or cool bet at print start can already make a few minutes difference with same g-code.