@sanglae-kim

we should include in the equation the extrusion multiplier because when this is not equal to 1 will give different results for E

Posted by: @misan

@sanglae-kim: I have followed your numeric example and found a few problems: 

>>> h**2/4*math.pi+w*(w-h)
0.13818583470577037

You were missing PI when calculating the section of the extruded path.

If you calculate the total length needed for the 80.078 mm path at 0.3 mm height and 0.45 mm width you get

def whatL(h,w,K):
    return (4*K*h*w+(pi-4)*K*h**2)/(pi*D**2)

>>> whatL(0.3,0.45,80.074)
3.8512856322385485

Which seems quite close to the E3.85132 in the second marked line. Maybe the small difference is due to the integer raster mentioned above. 

OTOH, extruder axis may be set to absolute or relative values independently of XYZ axis mode. 

I guess in this case it is set to relative(M83, something you can check at the beginning of the Gcode file) rather than absolute as you were assuming (otherwise there would be a significant calculation difference).

>>> h**2/4*math.pi+w*(w-h)
0.13818583470577037

You were missing PI when calculating the section of the extruded path.

If you calculate the total length needed for the 80.078 mm path at 0.3 mm height and 0.45 mm width you get

def whatL(h,w,K):
    return (4*K*h*w+(pi-4)*K*h**2)/(pi*D**2)

>>> whatL(0.3,0.45,80.074)
3.8512856322385485

Which seems quite close to the E3.85132 in the second marked line. Maybe the small difference is due to the integer raster mentioned above. 

OTOH, extruder axis may be set to absolute or relative values independently of XYZ axis mode. 

I guess in this case it is set to relative(M83, something you can check at the beginning of the Gcode file) rather than absolute as you were assuming (otherwise there would be a significant calculation difference).

If I understand correctly, what you want to do might work properly!

The difference between prusaslicer and my customized Gcode generator was very small. (maybe in some cases, this might become big)

I'm pretty sure your Gcode also works if you calculate correctly (the equation posted here is right)

Thanks

https://github.com/misan/gcodeFont

To my eyes it does not seem a huge difference but, unfortunately, I cannot shed any more light on a possible reason for that slight variation.

example infill pattern "line" at 20%.
e values per mm range = 0.054281 To 0.054399

Just a sample cube in vase mode. You can see that 3 of the sides render precisely the same E value. The fourth one is not because a slicing decision is made;  it will split it into two segments for reasons I ignore. But once you add these two together, 0.81863+0.01235, you get the same E value 0.83098 so at least in this example the idea that a certain distance renders a given E value holds.

Answering to @Heiko I reckon if layer height and width are the same, two lines of equal length would get the same E value from the slicer

@ misan i think so, but the amount of extrusion per mm differs, when the lenght is changing. (you can check it easily by comparing two
paths with diffrent lenght of any infill) i'm still wondering, where this might come from, but for my purpose i guess it's ok to just calculate
the mean of all e values (per mm) and then multiply with the pathlenghts of my one code