Cura doesn't do extrusion reset with G92 E0

[greg-smith 0]

[update - it does do this! sorry - could do it more often, though...]

I've noticed that Cura doesn't use 'G92 E0' lines like slc3r does.

As a result, you see the full extrusion towards the end of the print, e.g.

G1 X152.68 Y191.48 E18999.16459

G1 X152.97 Y191.93 E18999.19454

G1 X152.62 Y191.91 E18999.21392

 

This can be a problem for larger prints.

Here's the issue: there's only very small extrusions implied per G1 here - the last two lines differ by less than .02 mm. But in many prints the total extrusion can get to dozens of meters. As far as I'm aware, firmware like Marlin converts these numbers to 32-bit floating point, which has 24 bits of precision - about 7 or 8 significant digits. Specifically, once you reach 16.384 meters, the internal representation of these numbers is rounded to the nearest 1/512 mm (about 0.002 mm) . Once over 32.768 meters, it's rounded to the nearest 0.004 mm, etc. This rounding introduces fairly large differences between the extrusion rate intended by the G-code with all of its significant digits, and the extrusion rate which the firmware will determine after rounding the values to 32-bit floats (the good news is that the effect is worst on very short G1 segments, and the variations on those will tend to average out, but it means you're less likely to get a smooth operation of the extrusion motor).

 

The fix for this is to periodically issue a 'reset' of the extrusion, which is just

G92 E0

... and then you are back to a zero reference point. For instance,

(assuming the previous extrusion was to E18999.1) the following lines have the same effect without the loss of precision.

 

G92 E0 ; reset 18999.1 to 0

G1 X152.68 Y191.48 E0.06459 ; which is 8999.16459 in previous reference

G1 X152.97 Y191.93 E0.09454 ; etc

G1 X152.62 Y191.91 E0.11392

If the E numbers stay below 2000 mm, rounding will be to the nearest .00012mm at worst case.

Slc3r, I believe, does a reset at every retract, and possibly between layers too.

 

[Daid 306]

Actually, someone did the math on this:

https://github.com/Ultimaker/CuraEngine/issues/14

And I'm only resetting the E value at retractions right now. This has some internal code reasons.

 

[greg-smith 0]

OK, I stand corrected, I hadn't noticed the lone G92s. It seems it's being done every 10000 mm. Maybe a bit more often?

The post you gave mentions u=1.19e-07 as the relative error, this is good as a guideline, but the numbers I gave are accurate for conversions in numbers in the specific ranges. I.e.

values in range 8192.0 <= x < 16384 have a precision of 1/1024.

values in range 16384.0 <= x < 32768 have a precision of 1/512.

values in range 32768.0 <= x < 65536 have a precision of 1/256.

etc.

So, It would help if you could even reduce that limit from 10000 mm to 8000 mm, it would keep you out of that range.

(have made a longer comment on the github thread to the same effect).