Duet reporting inaccurate percentage.

Phaedrux

@Turbo said in Duet reporting inaccurate percentage.:

{if layer_z < max_print_height}G1 Z{z_offset+min(layer_z+40, max_print_height)}{endif} ; E Move print head up

What does this evaluate to in the sliced file?

Did this also start happening after tuning pressure advance as per your other thread?

Turbo

@Phaedrux If the final z height is under a defined value, itll raise 40mm to get out of the way, so long as it doesnt hit the max height. this didnt happen after tuning pa.

Phaedrux

Firmware and DWC versions?

Which percentage complete were you looking at?

Also, I meant what does that conditional line look like in the final gcode file?

Turbo

@Phaedrux
DWC: 2.0.7
Board: Duet WiFi 1.02 or later
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.05.1 (2020-02-09b1)
Duet WiFi Server Version: 1.23

Hits 82% or so every time, then jumps to completed.
I went back to stock prusa end gcode to see if it would resolve which looks like:

G4 ; wait
M221 S100
M104 S0 ; turn off temperature
M140 S0 ; turn off heatbed
M107 ; turn off fan
{if layer_z < max_print_height}G1 Z{z_offset+min(layer_z+30, max_print_height)}{endif} ; E Move print head up
G1 X0 Y200 F3000 ; E home X axis
M84 ; disable motors

This is what the processed code looks like for that end.gcode. I dont see any issues, but im not an expert.

;END gcode for filament
G4 ; wait
M221 S100
M104 S0 ; turn off temperature
M140 S0 ; turn off heatbed
M107 ; turn off fan
G1 Z31.95 ; E Move print head up
G1 X0 Y200 F3000 ; E home X axis
M84 ; disable motors

I cant seem to find anything abnormal in the gcode, but here it is. maybe you'll find something
V4_EarSavers_CCPrinter_5.gcode

Turbo

Im going to try copying the end gcode from my other printer (only changing one z value since its not as big), since that one reads percentage properly, and see if the issue persists.

Turbo

@Phaedrux
Print finished with the new gcode. Its not the end script causing it. it still ends at 82%, despite being the same end gcode on my other printer, which displays the percentage properly.
What else could it be

Turbo

tried another print with no end .gcode. I'm still having this issue.

Turbo

Is it possible the start gcode would cause this issue? Ive ran the same gcode (essentially, changing retraction/PA) on two printers and one correctly reads the percentage, while one finishes around the 82% mark, not the same value each time. 81.2, 82.6, and 82% is what ive witnessed.

Phaedrux

I can't see anything obvious in the gcode file.

Turbo

Bumping this topic because the issue remains unresolved. A print just finished at 55.8%

dc42

Are you referring to the % complete reported by DWC, or by PanelDue?

Those % complete figures are not based on object height, which is why your end GCode does not affect them. AFAIR the % complete figure is based on filament consumption vs. filament required (if the filament length required is available in the GCode file), otherwise on the percentage of the GCode file that has been processed.

Your sample GCode file has these figures:

; filament used [mm] = 6904.1
; filament used [cm3] = 16.6

; total filament used [g] = 0.0
; total filament cost = 0.0

The 6904.1mm figure is being picked up by RRF. Next time you print this file (or another file that shows the same issue), please monitor the Filament Usage value of the DWC status page towards the end of the print, to see whether it is converging towards the filament usage recorded in the GCode file, or towards a lower value.

I note that your GCode file contains some negative extrusion amounts:

G1 F8640.000
G1 X18.241 Y12.662 E-0.33092
G1 X19.422 Y11.978 E-0.31506
G1 X20.660 Y11.628 E-0.29710
G1 X21.913 Y11.463 E-0.29192
G1 E-0.06500 F2100.00000

I presume this means you have "wipe while retracting" or similar enabled in the slicer.

dc42

I've just run that file in simulation mode. It finished just after reporting 88% complete with >1m of filament remaining. This suggests to me that either RRF is accumulating filament usage incorrectly, or that PrusaSlicer is reporting incorrect filament usage for the particular options you are using.

I think that RRF may be being confused by wipe during retraction. Please can you try running that print in simulation mode and check that you get the same results as me (or run another file if you prefer, and note the % complete figure it reaches just before the end). Then slice that file again, turning off wipe-while-retract. Simulate that file and see if the behaviour is different.

Turbo

@dc42 running that .gcode I linked earlier shows a correct readout in simulation mode; reaching 100% as expected. I am referring to the DWC %

EDIT: i ran the file that finished at 55% from earlier in simulation mode, and it showed proper percentage up to 100%

dc42

@Turbo said in Duet reporting inaccurate percentage.:

@dc42 running that .gcode I linked earlier shows a correct readout in simulation mode; reaching 100% as expected. I am referring to the DWC %

EDIT: i ran the file that finished at 55% from earlier in simulation mode, and it showed proper percentage up to 100%

Strange, when I ran your file in simulation mode (using RRF 3.01-RC7) it definitely jumped from about 88% to 100%.

I am fairly sure that wipe-while-retract is confusing the filament used accumulator, but I don't know if that is the only issue here. Can you re-slice one of your prints with wipe-while-retract disabled and see if the problem goes away?

dc42

This is now fixed in the 3.01 source code and in the firmware binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

Turbo

@dc42 disabling wipe while retract solved it! Although am i able to use 3.01 with a duet 2 wifi board?

Board: Duet WiFi 1.02 or later
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.05.1 (2020-02-09b1)
Duet WiFi Server Version: 1.23

dc42

@Turbo said in Duet reporting inaccurate percentage.:

Although am i able to use 3.01 with a duet 2 wifi board?

Yes you can, however you will need to make substantial changes to your config.g file if you do upgrade. See https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_Summary_of_what_you_need_to_do_to_convert_your_configuration_and_other_files for the details.

The fix will probably make it to RRF 2 eventually, but not until it has been in RRF3 long enough for me to be certain that it has no unexpected side effects.

Turbo

@dc42 Got it, thanks. I always assumed the RRF 3 would only work for Duet 3 boards and later. IDK Why

Turbo

@dc42 After updating to RRF3.0 RC7, the issue is still present it seems. i have a current print about 50% done, however, the DWC only shows 6%, and i can watch it go up and down in percentage, which i dont think is supposed to happen. The object is consistent all the wey to the top, so there shouldnt be any large discrepancies that would affect %. This is with wipe while retract is on, because it does affect my print quality noticeably.

dc42

Yes the bug is present in the 3.01-RC7 release, but fixed in the post RC7 build that I linked to earlier.