Percentage calculation is weird

Jack0r

The percentage of the running print is kinda broken.

For example, I have a 12m print. When it's just about done with the first layer (of 36 layers, all roughly equally sized, 3m21s of 12m16s elapsed) it shows 54% done.

This is not a one-off, but happens on every print.

How can I fix this?

Repetier

Not really a bug but a result of what slicers do. For progress we count lines and there are a lot of comments at start and end to contain image/settings that can make a bigger difference especially on short prints with much long moves. So here you see it a bit better. Guess I should also count non comment and non empty lines for better comparison.

Jack0r

Repetier said:

Not really a bug but a result of what slicers do. For progress we count lines and there are a lot of comments at start and end to contain image/settings that can make a bigger difference especially on short prints with much long moves. So here you see it a bit better. Guess I should also count non comment and non empty lines for better comparison.

Makes sense, but I'm not sure if that's really the only issue. The numbers I mentioned above were somewhere in layer 2, so definitely before layer 3. The change to layer 3 happens on line 1343 in the GCode file that I was using. The whole file has 17521 lines, so that should be <8%, not 54%.

Also, would it possibly be better to calculate the percentage from total/elapsed print time? Or is the print time also just a function of the line count?

Repetier

Ok, I forgot we have changed that in the last versions. Not sure which. In past we used line/total line. That confused users too  much so now we use time vs total time. This is from a simulation, but there is also a jump at the beginning. How big depends on the heating speed you have entered in tools. Here we get a jump as soon as we send wait extruder/bed temperature assuming we start at room temperature. So as soon as the M code gets send the time passed jumps also it might some more minutes the printer is ready with heating. So on a 12min print with bed needing 6m it you get quickly a jump to 50% as this is time depending and 50% of time consuming commands got send. A bit unsharp as we don't know when a command gets really executed. But that is why you see it.

Jack0r

Repetier said:

Ok, I forgot we have changed that in the last versions. Not sure which. In past we used line/total line. That confused users too  much so now we use time vs total time. This is from a simulation, but there is also a jump at the beginning. How big depends on the heating speed you have entered in tools. Here we get a jump as soon as we send wait extruder/bed temperature assuming we start at room temperature. So as soon as the M code gets send the time passed jumps also it might some more minutes the printer is ready with heating. So on a 12min print with bed needing 6m it you get quickly a jump to 50% as this is time depending and 50% of time consuming commands got send. A bit unsharp as we don't know when a command gets really executed. But that is why you see it.

Oh, this makes a lot of sense now. Yes, my heating speed is default, and that's really low. Didn't know that setting existed, thanks!

What do you think, would it make sense to autotune that? So on every heatup, repetier server could measure how long the heating took and what's the temperature difference and thus adjust the values.

Repetier

Normally it is enough to run the wizard in server to determine the speeds. Just set them to your typical bed/extruder temperature. Makes prediction more exact regarding total time.