prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.8k stars 1.94k forks source link

Filament usage estimates differ between UI and output file #8176

Open DrLex0 opened 2 years ago

DrLex0 commented 2 years ago

Description of the bug

The total filament used estimate that is written to gcode files is not the same as what is shown in the UI.

Filament-used-UI Filament-used-file

After some investigating, the difference is that the UI includes extrusions performed in the start G-code (shown as “Custom” in the viewer), while the output file does not. The “total filament used” and “total filament cost” values in the G-code file should also include the “custom” estimate, otherwise it is not really total.

Project file & How to reproduce

Project-and-output.zip

  1. Slice and export
  2. Compare Sliced Info in the UI with the comments in the gcode file

Checklist of files included above

Version of PrusaSlicer

Version 2.4.2-rc1+x64

Operating system

Mac OS 10.14.6

Printer model

FlashForge Creator Pro

foreachthing commented 2 years ago

Seams to be fixed in 2.5.0 a0: (it's Windows, though...) image

DrLex0 commented 2 years ago

@foreachthing Try it with the .3mf file attached to this issue. If your start G-code doesn't do any extrusions, you won't encounter this issue.

foreachthing commented 2 years ago

Ok ... it shows the same on my computer with your .3mf and your settings. If I import your model (just the model!) and slice it for my printer, it's all good! So, my point is, that there is something going on with your profile.

That's my start gcode:

; Printer_Settings_ID: [printer_settings_id]

; # # # # # # START Header
G21         ; metric values
G90         ; absolute positioning
M82         ; set extruder to absolute mode

M140 S[first_layer_bed_temperature] ; start bed heating

G28 X0 Y0 Z0    ; move X/Y/Z to endstops
G0 X0 Y1 F15000 ; move X/Y to start position
G0 Z20 F9000    ; move Z to start position

; Wait for bed and nozzle temperatures
M190 S{first_layer_bed_temperature[0] - 8}  ; wait for bed temperature - 5
M140 S[first_layer_bed_temperature] ; continue bed heating
M109 S[first_layer_temperature] ; wait for nozzle temperature

; BONDTECH Extruder (uncomment if you have one);
; Make sure this comes before any extrusions
M92 E492.45

; Purge and prime
M83          ; set extruder to relative mode
G92 E0           ; reset extrusion distance
G1 F100 E23      ; compress the bowden tube
G92 E0           ; reset extrusion distance
G1 E-7 F1200     ; RETRACT

G0 X{print_bed_max[0]*0.1} Z20 F3600
G0 X{print_bed_max[0]*0.4} Z{nozzle_diameter[0] * 3}
G0 X{print_bed_max[0]*0.5} Z{nozzle_diameter[0]} F1200
G0 Y7
G1 E7 F1200      ; UNRETRACT
G92 E0           ; reset extruder reference
M82          ; set extruder to absolute mode
; # # # # # # END Header
DrLex0 commented 2 years ago

Comparing start code between totally different printers is a bit pointless, although it does illustrate when this issue happens and when not. You aren't extruding anything in your start code, you are merely retracting and unretracting, which is why your numbers match. My start code does an actual extrusion which accounts for the difference between the filament usage shown in the UI and the “total” in the file. They just need to add the value shown for “custom” in the slicing preview to this “total” value and the issue is fixed.

foreachthing commented 2 years ago

That extrudes G1 F100 E23... does it not?

DrLex0 commented 2 years ago

It looks like only G1 commands with an X or Y argument are treated as extrusions that consume filament. Your G1 command is also counted as an (un)retract, and is not added to the ‘custom’ count. Try adding X and/or Y movement, and you'll see it will be counted.

foreachthing commented 2 years ago

G1 is not the culprit, I think. Watch this: Start G-Code: image Left, no x-move, just extrusion. Right, x-move and extrusion.

Stats: image Left and Right same amount of filament used.

And what PS predicted: image

PS thought it would use 810 mm (rounded somewhere) and the G-code should only use 614 mm. So, I share your conclusion: g-code is wrong.

lukasmatena commented 2 years ago

Thanks, we'll look into it.