You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
No response
Are you looking for hardware support?
No response
Describe the feature you want
After some battling with PID i realized, that it would be easy to have a PID tune manger, that could automatically apply different PID tunes depending on target temperatures. While this could ba achieved by adding M301 calls in slicer, having this in the firmware is neater, has less potential for errors and also would allow for auto-tunning various temperatures in one process on the printer. This should not add much data to settings saved - in typical application 5 tune set is already plenty.
The upside is, that it would result in much more stable hot end temperature, and that often translates to better quality prints.
The downside I see, is that there are no G-code calls that support this kind of behaviour (that I know of at least). So this would entail quite deep changes.
I would welcome input on the idea from maintainers.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Have you explored MPCTEMP for the hot-end? This tends to hold its stability much better.
An adaptive PID would be interesting, and I'm sure there are some implementations out there that could be used for reference.
Of course, we are welcome to all experimentation in these areas as we might discover new and better ways to tune and maintain ideal extrusion on machines without a lot of extra sensors. Observing temperature behavior is one way to indirectly measure material mass.
Any adaptation needs to account for the changing rate of extrusion and presence of material in the melt zone because faster extrusion pulls more watts out of the hotend. Generally we adjust the amount of flow to account for increased slippage in the extruder at higher rates, among other things. (e.g., See the NONLINEAR_EXTRUSION feature.) The delay in response in PID makes it easier to tune under controlled conditions than under constantly-changing conditions.
Oops, forgot to specifically mention the "PID tune mangler"
We do love manglers. If the hotend does show different characteristics for 190°C versus 240°C then being able to store and select between those different PID values would be cool. Basically, just need to add an "index" parameter to the PID tuning save function(s) so when the results are stored they go into a slot labeled with the temperature.
When starting a print you would just select the PID by index, or if you specified a temperature, then it could pick the PID with the closest temperature.
Not too fundamentally different, but it would need to be built out, and a UI created for MarlinUI and each of the other controllable displays we support. Could be useful for some!
Is your feature request related to a problem? Please describe.
No response
Are you looking for hardware support?
No response
Describe the feature you want
After some battling with PID i realized, that it would be easy to have a PID tune manger, that could automatically apply different PID tunes depending on target temperatures. While this could ba achieved by adding M301 calls in slicer, having this in the firmware is neater, has less potential for errors and also would allow for auto-tunning various temperatures in one process on the printer. This should not add much data to settings saved - in typical application 5 tune set is already plenty.
The upside is, that it would result in much more stable hot end temperature, and that often translates to better quality prints.
The downside I see, is that there are no G-code calls that support this kind of behaviour (that I know of at least). So this would entail quite deep changes.
I would welcome input on the idea from maintainers.
Additional context
No response
The text was updated successfully, but these errors were encountered: