How is the percentage complete calculated?

[dc42]

@achrn can you share the GCode file?

[achrn]

@dc42 the full file is over the upload limit (only slightly, I think - it's about 5MB).

It's gcode generated by perl code which basically take a program in turtle graphics type instructions and converts it to gcode. Something I thought might upset it is that there's about as much comment text as instruction text (see below).

The firmware thinks it's a cartesian kinematics with an X range of 0 to 300 and a Y range of -3600000 to +3600000 - because it's actually a continuous rotation polar mechanism with X being radius in millimetres and Y being angle in degrees and I've never needed to go above 10,000 revolutions. The perl generates the polar coordinates, segmenting each turtle move (gcode instructions at about 5mm of path spacing) and calculating the feed speed so that the actual linear feed speed is constant.

This particular file starts at Y of 475 and finishes at Y of -51545.

I've just run the file again and it actually finished (the highest number reported before it stopped) at 485.7%. It then jumps back to 100% when it stops.

As previously noted, it's not Duet hardware, so it's not Duet version of the firmware - it's RepRapFirmware for STM32F4 based Boards 3.3.0_10 (2021-11-05)

File starts:

; eccentric circles
;   centre:       79.61 -172.45
;     eccentricity: 189.93
;     direction: 1
;     spacing: 2.06
; peripheral position at angle 474.780
G1 F1000
G1 X300.00 Y{360.0*floor((move.axes[1].machinePosition+180)/360)+474.780}
G92 X300.00 Y474.780
; left
; right
; turn through -180.000 degrees centred at 79.61,-172.45
G1 X300.00 Y473.825 F573.0; seg 1/308 to -121.19,274.45 - r.limited
G1 X300.00 Y472.871 F573.0; seg 2/308 to -116.62,276.47 - r.limited
G1 X300.00 Y471.917 F573.0; seg 3/308 to -112.03,278.45 - r.limited
G1 X300.00 Y470.964 F573.0; seg 4/308 to -107.42,280.38 - r.limited
G1 X300.00 Y470.011 F573.0; seg 5/308 to -102.80,282.27 - r.limited
G1 X300.00 Y469.058 F573.0; seg 6/308 to -98.15,284.10 - r.limited
G1 X300.00 Y468.107 F573.0; seg 7/308 to -93.48,285.89 - r.limited
G1 X300.00 Y467.156 F573.0; seg 8/308 to -88.80,287.64 - r.limited
G1 X300.00 Y466.207 F573.0; seg 9/308 to -84.10,289.33 - r.limited
G1 X300.00 Y465.259 F573.0; seg 10/308 to -79.38,290.97 - r.limited
G1 X300.00 Y464.312 F573.0; seg 11/308 to -74.64,292.57 - r.limited
G1 X300.00 Y463.367 F573.0; seg 12/308 to -69.89,294.12 - r.limited
G1 X300.00 Y462.424 F573.0; seg 13/308 to -65.13,295.62 - r.limited
G1 X300.00 Y461.482 F573.0; seg 14/308 to -60.34,297.07 - r.limited
G1 X300.00 Y460.542 F573.0; seg 15/308 to -55.55,298.48 - r.limited
G1 X300.00 Y459.605 F573.0; seg 16/308 to -50.74,299.83 - r.limited
G1 X300.00 Y458.669 F573.0; seg 17/308 to -45.91,301.14 - r.limited
G1 X300.00 Y457.736 F573.0; seg 18/308 to -41.08,302.39 - r.limited
G1 X300.00 Y456.805 F573.0; seg 19/308 to -36.23,303.60 - r.limited
G1 X300.00 Y455.876 F573.0; seg 20/308 to -31.37,304.75 - r.limited
...

towards the middle where it's not limited to the mechanism limiting radius:

...
G1 X119.51 Y-34040.786 F1890.4; seg 164/181 to -111.73,42.41
G1 X117.24 Y-34042.941 F1877.4; seg 165/181 to -107.97,45.70
G1 X115.07 Y-34045.159 F1864.5; seg 166/181 to -104.15,48.92
G1 X113.00 Y-34047.442 F1852.0; seg 167/181 to -100.28,52.08
G1 X111.03 Y-34049.790 F1839.8; seg 168/181 to -96.36,55.17
G1 X109.18 Y-34052.203 F1828.2; seg 169/181 to -92.38,58.19
G1 X107.44 Y-34054.680 F1817.3; seg 170/181 to -88.36,61.14
G1 X105.83 Y-34057.220 F1807.1; seg 171/181 to -84.28,64.02
G1 X104.35 Y-34059.820 F1797.9; seg 172/181 to -80.15,66.82
G1 X103.01 Y-34062.478 F1789.5; seg 173/181 to -75.97,69.56
G1 X101.80 Y-34065.190 F1782.2; seg 174/181 to -71.75,72.22
G1 X100.75 Y-34067.952 F1775.9; seg 175/181 to -67.48,74.81
G1 X99.85 Y-34070.758 F1770.6; seg 176/181 to -63.16,77.33
G1 X99.10 Y-34073.602 F1766.3; seg 177/181 to -58.81,79.77
G1 X98.52 Y-34076.478 F1762.9; seg 178/181 to -54.41,82.13
G1 X98.10 Y-34079.378 F1760.4; seg 179/181 to -49.97,84.42
G1 X97.85 Y-34082.295 F1758.8; seg 180/181 to -45.49,86.63
G1 X97.77 Y-34085.220 F1758.0; seg 181/181 to -40.98,88.76
; right
; turn through -180.000 degrees centred at 80.47,-174.32
G1 X97.85 Y-34088.134 F1758.0; seg 1/183 to -36.44,90.81
G1 X98.10 Y-34091.040 F1758.8; seg 2/183 to -31.87,92.78
G1 X98.52 Y-34093.929 F1760.5; seg 3/183 to -27.27,94.67
G1 X99.10 Y-34096.794 F1763.0; seg 4/183 to -22.64,96.48
G1 X99.84 Y-34099.628 F1766.4; seg 5/183 to -17.98,98.21
G1 X100.74 Y-34102.423 F1770.8; seg 6/183 to -13.28,99.86
G1 X101.79 Y-34105.175 F1776.1; seg 7/183 to -8.56,101.43
G1 X102.99 Y-34107.877 F1782.5; seg 8/183 to -3.82,102.91
G1 X104.33 Y-34110.525 F1789.9; seg 9/183 to 0.96,104.32
G1 X105.80 Y-34113.116 F1798.3; seg 10/183 to 5.75,105.64
G1 X107.41 Y-34115.647 F1807.6; seg 11/183 to 10.57,106.89
G1 X109.14 Y-34118.115 F1817.9; seg 12/183 to 15.41,108.04
G1 X110.99 Y-34120.519 F1828.9; seg 13/183 to 20.26,109.12
G1 X112.94 Y-34122.859 F1840.6; seg 14/183 to 25.14,110.11
G1 X115.01 Y-34125.135 F1852.8; seg 15/183 to 30.03,111.02
G1 X117.17 Y-34127.346 F1865.5; seg 16/183 to 34.93,111.84
...

file ends

...
G1 X300.00 Y-51543.958 F573.0; seg 304/307 to 298.45,-610.79 - r.limited
G1 X300.00 Y-51544.379 F573.0; seg 305/307 to 293.98,-612.99 - r.limited
G1 X300.00 Y-51544.800 F573.0; seg 306/307 to 289.48,-615.16 - r.limited
G1 X300.00 Y-51545.220 F573.0; seg 307/307 to 284.95,-617.27 - r.limited
G0 X300

[chrishamm]

@achrn What software version are you using?

Recent versions of DWC try to use the amount of filament extruded vs total filament during a live print and the file progress as a fallback (current byte position vs total file size). The filament-based progress value may not exceed 100% but it may be greater for the fallback if the current file position is greater than the file size (which should never happen).

[achrn]

@chrishamm I think I have worked out what it is doing.

First, to answer the questions about software version, it is v 3.3.0 firware from the teamgloomy port for STM32F4 (Mellow E3 Pro board). M122 reports 'RepRapFirmware for STM32F4 based Boards (fly_e3_pro) version 3.3.0_10 (2021-10-17 16:57:38) running on STM32F4' and this morning I've added a fresh download of DuetWebControl-3.3.0-SD.zip from GitHub (though it was 3.3.0 before).

I made a new file (similar sort of path, but many fewer loops and finishes in about 15 minutes), the first time I uploaded and printed it the percentage complete didn't increment at all - it stayed at 0.0% for the duration of the print, then jumped to 100% when complete. I then hit 'print again' and second and third times it tracked sensibly up to 100%, apparently correctly in proportion to how far it was through the file.

Then I tried the first file (foobar.g) again (printing it from within the 'jobs' screen, not re-uploaded. First time it got to 100% progress when it was about 12% of the actual way through the file, but then I did 'print again' and it was initially going correctly (was showing 12% when it was about 12% through the file at which point I stopped it), printed it a third time (this time from the jobs screen) and again it started correctly (was showing 12% when it was about 12% through the file at which point I stopped it).

So then I made a new file foobar3.g which is the first 12% (ish) of foobar.g. Upload that and print it and when the file was complete it said it was 12% (ish) progress. But print again, and it tracked properly up to 100%. Print again, tracked properly to 100%. Repeated several times, always reported progress properly.

So then I made a file foobar4.g that's half as long as foobar3.g. Upload and print that, and progress counts up to 50.0% at the end.

Print foobar3.g again (from the 'Jobs' screen) and it counts up to 200.0%.

So I think it's calculating the percentage complete as the distance through the current file divided by the length of the previous job file. Every time I print the same file multiple times in succession I get correct progress. If I print a file that's 1/8 as long as the file I just printed, progress only gets to 12%. If I print a file that's 8 times longer, progress is heading towards 800%. Print a file half as long and it finishes at 50%, twice as long and it finishes at 200%. For the first job printed after a M999 the progress percentage doesn't increment at all (as if the 'previous file' was infinitely long, I suppose).

I think the time estimation based on file progress seems correct - it does seem to know how long the current file is, even if it's a different length to the previous file.

[dc42]

@achrn please try firmware 3.4.0rc1 and see if the issue is still present.

[achrn]

@dc42 3.4.0rc1 is not ported yet (at least, I can't find it), and 3.4.0b7 doesn't work for me (I'll post separately about that).

[jay_s_uk]

@achrn RC1 should be out tomorrow

[achrn]

@jay_s_uk Fantastic, thanks. I'll hold off writing out what isn't working for me with b7 until I've tried RC1 then.

[achrn]

@dc42 updated to 3.4.0rc1 and the issue is still present, so if I print the 4.7MB 'foobar.g' file immediately after a 8kB file I get a magnificent 59,589.5% complete:

However, I've found that it doesn't always happen. I can't work out what makes it happen.

I've made a 300 line file (foobar_300.g), a 2,000 line file (foobar_2000.g), and a 5,000 line file (foobar_5000.g). Files sizes are 8.1, 55.1, 139.3 kiB respectively.

The last dozen runs:
I printed foobar_300.g and progress tracked correctly.
I printed foobar_5000.g and progress was wrong - reaching some high number.
I printed foobar_2000.g and progress tracked correctly.
I printed foobar_300.g and progress tracked correctly.
I printed foobar_5000.g and progress tracked correctly.
I printed foobar_300.g and progress tracked correctly.
I printed foobar_5000.g and progress tracked correctly.
I printed foobar_300.g and progress tracked correctly.
I printed foobar_5000.g and progress was wrong - reaching 1710.1%
I printed foobar_300.g and progress tracked correctly.
I printed foobar_5000.g and progress tracked correctly.
I printed foobar_2000.g and progress tracked correctly.

So 300 is always right, 5000 is sometimes right, sometimes wrong. 2000 is always right, I think, but I've printed it fewer times.

[dc42]

@achrn you will need to make those files available to us somehow (e.g. via Dropbox or Google Drive) if you want us to look into this issue.