Estimate of filament used should be calculated before applying extrusion multiplier

[DrLex0]

Version

Any recent one (verified in 1.3.0-dev-13f121e)

Behavior

• The extrusion multiplier should not be included in the estimates of used filament and cost. These values should be based on the non-multiplied coordinates, or there should be an option to calculate them as such.
• Steps needed to reproduce the problem
  • Slice any model with any set of settings where filament density and cost are specified, and note the estimated amount of used filament and cost of the print.
  • Slice it again after only changing the filament extrusion multiplier.
• Expected Results
  • The estimates are the same
• Actual Results
  • The estimates change

I believe extrusion multiplier is generally poorly understood, and many use it as a general-purpose fudge factor to compensate for poor configuration elsewhere (there are some feature requests here in GitHub in this vein). The true purpose of the extrusion multiplier is to compensate for the discrepancy between what the slicer tells the printer to extrude, versus what it actually extrudes. This varies per filament type due to squishiness and how deep the extruder gear teeth bite into the material.
This means changing the extrusion multiplier should have no effect on the estimate of consumed filament and cost for a particular print, because the multiplier's purpose is exactly to ensure that the extruder outputs what we ask it to. If Slic3r computes from filament diameter, layer thickness, and extrusion width, that a certain print requires 100 mm of filament, then it should assume the actual amount of filament going through the extruder will also be 100mm, no matter what the multiplier is.

For me this is not a big deal because I have a high-precision scale and I iteratively adjust density based on actual versus predicted weight of prints until they match, but this means the density value I need to enter in Slic3r deviates the more from the actual physical value, the more the extrusion multiplier deviates from 1. Anyone relying on values from the manufacturer or measured in a lab, will end up confused.

In an ideal world, Slic3r would completely ignore extrusion multipliers (in the same way as it ignores filament diameter for volumetric E). It would only write them to the G-code file as configuration. Whatever software interprets the G-code (printer firmware, or a program like GPX) should then read those extrusion multipliers and apply them while converting E coordinates to stepper motor steps. Because there seems to be no standard way to do this however, we're stuck with writing skewed E coordinates, but we should at least be aware of this…

If we want to keep a fudge factor that truly instructs a change in extruded material amount, it should be separate from the extrusion multiplier.

[Tinchus2009]

I think you are worng. Basically, if you use , lets say 0.9 extrusion multiplier, the extruder will extreude less plastic than useing an extrusion multiplier of 1. So yes, the cost calculation seems ok

[DrLex0]

@Tinchus2009 Suppose I configure Slic3r to print a solid 10x10x10mm cube with a filament of 1.75mm diameter, at 100% infill. From that information alone, we can calculate exactly the length and volume of plastic that should ideally go into the cube. The volume is obviously 1000mm³ and the length is 1000/(π*0.875²) = 415.75mm.
Now why would anyone set the extrusion multiplier to 1.1 in this case, to try to shove 1100mm³ of plastic into a volume of 1000mm³? No, the reason is because we know our extruder under-extrudes by a factor 1/1.1 for this filament, therefore to truly print a perfect solid 1000mm³ cube, we need this extrusion multiplier of 1.1. By doing this, our printed cube will truly contain 1000mm³ of actual printed material, therefore this is also what Slic3r should show as the estimate.

(Curiously, if I actually do the above with a multiplier of 1.0, I rarely get an estimate of exactly 1000mm³. This is probably due to accumulation of rounding errors. Of course the estimate is always pretty close to 1000.)