Additional variable to define max temp a heater can be set to

Features
1

I think it would be quite nice to be able to have an additional variable for heaters which defines the max temp a heater can be set to(like defined 280 as max_temp and 260 as max_set_temp so you can only set the heater to 260 via a command but the adc out of range shutdown would still only occur when the thermistor reads 280)
The reason is, I am using a phaetus rapido which has a quite powerful heater that overshoots quite a bit when heating up so having this feature would reduce the chance of accidentally setting a temp which would cause the overshoot to go over the allowed temp.
Technically it is not nescessary since you can just remember how much it overshoots but we are all human an make mistakes and that would prevent those.

I have already written an implementation for it which would be fully backwards compatible since it defaults the value to max_temp so it would be a seamless upgrade and people not wanting to use it don’t have to worry about it at all.

My approach was adding this:

        self.max_temp = config.getfloat('max_temp', above=self.min_temp)
        self.max_set_temp = config.getfloat(
            'max_set_temp', self.max_temp,
            minval=self.min_temp, maxval=self.max_temp)
        self.sensor.setup_minmax(self.min_temp, self.max_temp)

and changing the set_temp command a bit:

    def set_temp(self, degrees):
        if degrees and (degrees < self.min_temp or degrees > self.max_set_temp):
            raise self.printer.command_error(
                "Requested temperature (%.1f) out of range (%.1f:%.1f)"
                % (degrees, self.min_temp, self.max_set_temp))
        with self.lock:
            self.target_temp = degrees
2

Hello @LastZeanon !

Ever did a PID tune?

3

yep, but it still overshoots
When printing, the temp is perfectly stable, but when heating up, it overshoots by up to 10°
considering it’s a 115W PTC I’m not surprised though

If you have another idea to prevent the overshoot, I’m open to it.

I know my solution is not fixing the cause but rather the consequence but rn, I don’t have any idea how to fix the issue itself other than using another hotend which I would rather not since I’m quite happy with my rapido

4

A few thoughts:

  • I assume the thermistor has well contact to the heater block and is in good condition?
  • Assuming you run on 24V, the heater cartridge is rated to that voltage?

You may vary the value of this in [extruder]

#smooth_time: 1.0
#   A time value (in seconds) over which temperature measurements will
#   be smoothed to reduce the impact of measurement noise. The default
#   is 1 seconds.

From: Overheating hotend after PID tune

5

Thermistor is integrated, so I have no control over how well it is placed
But the hotend is not overheating but rather overshooting and then recovering
I dont think the problem can be solved by smoothing since the heater has basically no thermal mass (ceramic heatblock) combined with a 115W PTC Heater
It is basically an error by design which is not an error(cause having some overshoot when heating up but being stable when printing is not really a problem imo)
having high power on something with nothing to counter that power will result in an overshoot
It isn’t really a problem for me since I am already running a modded klipper version(to have my neopixel blink red when my mcus enter a shutdown state and to be able to read the internal temp sensor of my arduino uno) but I figured, it might be interesting for other people as well

6

Under certain edge cases the PID performance can be improved. This is a known fact.
There is already a quite advanced pull request that tackles exactly this: https://github.com/Klipper3d/klipper/pull/5955

Surely would be a valuable feedback if this improves the situation on your side.

The max_temp setting for me would be a bandaid and just increase configuration complexity for a handful of edge cases.

2 Likes
7

Thanks for the suggestion, I’ll try it out once I’m back at my printer and leave feedback
I also get your complexity point, which is why I coded it to be an optional value which defaults to the old behaviour

8

@Sineos here is the promised feedback:
Using the code from the pr with the default pid algorithm did about nothing, it might have even made the fluctuations after it settled a bit worse
Using pid_v though completely removed the overshoot
I’ll do some more in-depth testing with different accuracy settings later and also leave some feedback on the pr

2 Likes
9

Yeah, the regular PID is about the same as today. pid_v is a nice addition especially for such corner cases. Thanks for testing.
Ping @DanS

10

I will
I just need some more time to do more extensive testing (especially testing my bed will take a lot more time than testing the hotend)
I’ll get to there tomorrow

11

I already posted on the pr but I also wanted to thank @Sineos sincerely for the heads up:
After some more extensive testing I can confirm that pid_v basically completely eliminated my issue.
Maybe I will get some overshoot when deviating too much from the temp the Pid values were calibrated to but since I am working on implementing PID-Profiles rn that does not concern me too much.