I’m using the min_temp =0.5*target_temp -6, just because it works for me, But 0,85 is to high, considering that the target temperature is the bed temperature and the heatsoak temperature is the chamber one.
Using a array is a solution, but I really think that is too over for this problem. The heat soak process is long. Update faster than 30s really don`t make too much sense for me. And the moving average (the technique that you mentioned) has a small problem in the begining, since you don’t have measurements in t-1. Any way, I really think that just adjusting the sampling rate is enought to solve the problem (it solved for me).
Ok @SinisterRj, you are getting everything on your wish list, plus some more:
Smoothing of both the soak temp and soak temp rate are in. Each with a separately tunable smoothing factor in seconds. I’ve tested tested down to 0.1C/m and it seemed to work in my printer. 0.3C/m is the default, at that rate it would take an hour to got up 18 degrees C. The rate is smoothed using least squares to find the slope. I found this to be much better than a simple slope between 2 points in time. Default is a sample of 20 points.
Smoothing waits for the requested number of data points before computing a temp or rate. The script is not fooled by initial temperature sensor noise and wont quit early.
SOAK_TEMP lets you prolong the soak until the soak temp reaches at least that value.
M117 calls and message formats have been combined with logging. Soaking messages now show the temp, rate and timeout information.
Both heating and soaking phases have separately customizable reporting intervals.
The loop now evaluates the temps every 1 second. More samples is better for noise suppression and the uncoupled reporting intervals means you wont see any additional messages.
renamed CALLBACK to CONTINUE so its less “programmer-speak”
Added CANCEL which allows you to pass the macro to call when the heat soak is canceled. Default on cancel is to take no action. This prevents potential errors when heat soaking before a print and saves you from having to customize the macro.
mwu’s Pause/Resume functionality now only activates if there is a print running. This stops Klipper Screen from thinking a print is paused when heat soaking without a print actually running.
Apply rounding to temperatures so that small fractions don’t make it look like 90.0 < 90.0 is true.
If we RESUME before the CONTINUE macro, things work “as expected”, but if anything goes wrong in the CONTINUE macro it wont stop the print as it should. Not stopping in a crashed state is a deal breaker for me, clearly that’s not safe.
If we RESUME after the CONTINUE macro any state that you built up in the CONTINUE macro is lost, including any probed Z Offset and the current position of the toolhead. RESUME will reset all of this and move the toolhead back to the position it was in at the start of the HEAT_SOAK. That’s also a deal breaker for me. The whole point of CONTINUE was to do probing after the heat soak.
So option 3 is to remove the CONTINUE functionality and recommend that people split their PRINT_START up into 2 calls in their slicer like this:
# Bed heat-up, Nozzle pre-warming, Homing/QGL, park in center, HEAT_SOAK:
PRINT_WARMUP=[first_layer_temperature] BED_TEMP=[first_layer_bed_temperature]
# bed mesh, auto calibrate Z, final nozzle heat up and prime line
PRINT_START=[first_layer_temperature] BED_TEMP=[first_layer_bed_temperature]
I think this will makes the most sense for most users. The Pause state only covers the heat_soak time, nothing more. No weird syntax for passing a callback etc.
If you have a strong opinion on the CONTINUE functionality staying in or an alternative idea for making it safe to use, I’d love to hear it.
(I was using CONTINUE for macros that printed a test pattern, but I think I can find another way of doing that, like a small .gcode file)
CONTINUE was renamed to COMPLETE and the documentation was updated to reflect my view that most people would be better off splitting their PRINT_START macro in 2 and calling both parts from their slicer’s gocde.
Added overrides for CANCEL_PRINT and RESUME. These wrap any macros you may have and add functionality. Particularly RESUME allows you to skip the soaking phase but wont resume the print while heating. This makes buttons in front ends safe to press without weird side effects.
I’m doing that with node-red and the moonNode node. I monitor the stage variable of the HEAT_SOAK macro and send a notification when that changes to done. I’m in the middle of a move and my HA setup is offline, otherwise I’d share the full details. You could use HA’s native RESTful integration to poll moonraker’s API and create an entity with that same information, which would allow for creating the notification directly in HA.
i want to ask why gcode heat_soak can no longer be used? earlier every time i run heat_soak TARGET=100 DURATION=5 100c for 5 minutes then the heater turns off but now it keeps turning on. i didn’t change any gcode macros. is it related to me updating klipper and fluidd?
I run HEAT_SOAK TARGET=105 DURATION=5 my toolhead goes home and moves to the middle, but the heater_bed continues to turn on and doesn’t turn off. Usually after 5 minutes the heater automatically turns off?
I have recently updated mainsail v2.5.0 to which the periodical updates of the initial macro during the heatsoak process no longer shows under the main status bar but the macro still seems to work. What may be causing this?
