On PID_ADD_EXTRUSION_RATE and ballparking DEFAULT_Kc

[docpayce]

Though PID_ADD_EXTRUSION_RATE still being somewhat experimental, I think we might be able to implement it a bit better. Right now, DEFAULT_Kc is set to an arbitrary 100 - with no reason at all.

As far as I read the code in temperature.cpp correctly:

cTerm[e] = (lpq[lpq_ptr] / axis_steps_per_unit[E_AXIS]) * PID_PARAM(Kc, e);
pid_output += cTerm[e];

The value of Kc can be understood as

Additional_Heating_power = EXTRUDER_WATTS*(DEFAULT_Kc/255)*Extruder_Speed_in_mm/s

... or is it mm/min? I think mm/s.

If I am right, the rest is pretty straight forward:
For 1 mm of filament

density * (diameter/2)^2 * 1 mm

mass have to be heated up. That gives:

(((Melting temperature - Room temperature) * Heat capacity) + Fusion enthalpy) * mass =
= (((Melting temperature - Room temperature) * Heat capacity) + Fusion enthalpy) * density * (diameter/2)^2 * 1 mm

For PLA thats roughly 1.17 J per mm filament (1.75 mm diameter, heat capacity 1.8 J/gK, density 1.25 g/cm^3, Fusion enthalpy 93 J/g, Melting temperature 185°C, room temperature 20°C). Or 1.17 W of heating power for 1 mm/s feed speed.

For me, EXTRUDER_WATTS is 41W (3.5 Ohms), so DEFAULT_Kc should be set to (1.17/41) 255 =
7 or 8ish. If I missed something and the e_speed is given in mm/min, than it should be (1.17/41) 255 60 = 437.

For ABS the numbers pretty much land in the same ballpark. I calculated it to be 0.99 W heating power for 1 mm/s (1.75 mm diameter, heat capacity 1.3 J/gK, density 1.1ish g/cm^3, Fusion enthalpy 100_ISH_ J/g, Melting temperature 230°C, room temperature 20°C).

If I got my numbers right and if you agree, I will prepare a more concise comment for the configuration_adv.h section, which gives a more reasonable Default_Kc. One could even think about adding options to adjust for altering filament diameters.

[thinkyhead]

@docpayce My apologies for this issue sitting around for so long without a reply.

I agree that PID_ADD_EXTRUSION_RATE is still very much at an experimental stage and deserves more attention. I'd be interested also to see how some other firmware implements this (if indeed any of them do). If you're able to do some experimentation and come up with reasonable numbers and/or better methods of compensating, I would be interested in seeing it integrated into future versions of Marlin.

Probably the better place to discuss this would be in the MarlinDev issues, since we're focusing on existing releases and getting the next bug-fix release ready in this repo.

[docpayce]

Hey!

No need to apologize. :)

To my knowledge, Repetier crew plans to implement something similar in future versions of Repetier firmware, but nothing definitive yet. Also from my side, I am more on hardware designing side right now. :) But if anythin crosses my path, I will let you know. Thank you!

[thinkyhead]

Thanks, keep in touch! Refer back to this issue when you post a new one on dev.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.