Closed Errandir-of-Gondolin closed 12 months ago
I've known about this issue since the early days of this printer. Glad it's fixed! Will compile and test.
Thanks for reporting.
Another day, some more info. Sadly what I previously reported might not be an actual fix.
Context: today I resumed my calibration of the SV06. I started with the paper test, to set the z-offset. As soon as my nozzle dipped below 0 height (at which point the nozzle still didn't touch the bed), I got the same error: MCU temp out of range, back to -400°C. I recalled it was at the same exact moment in my calibration yesterday that this first popped up. So that got me thinking.
Sure enough, even reflashing the latest firmware didn't do anything. Probably because the probe was still at the same distance from the bed when rebooting the firmware, causing the same issue.
Temporary solution:
But as soon as you lower the printhead low enough (but still before the nozzle is close enough to the bed), the same error occurs and you need to start the process all over again.
I dialled in the z-offset via probe_calibrate, without the MCU_temp section in the cfg file, and I managed to set it to a value (default was 0, calibrated was around 1.5). I hoped that with a properly calibrated z-offset, the probe wouldn't be going too low for this to happen anymore, but sadly it is very repeatable. I don't even have to go to negative z-height values; lowering the nozzle to 1mm off the bed is enough for the error to trigger and shut everything down. The probe still is about 2.5mm above the bed at that point.
I have no idea how a seemingly probe-related issue can lead to unrealistic mcu temperature measurements, but here we are. For now I need to leave the mcu_temp section out of the config file to be able to proceed, but I'm concerned about the mcu not being monitored (including for too high temps). Not sure if there is actually any protection built into Klipper based on mcu temps going too high, but if there is, it might not function and hence increase the fire hazard of the printer.
UPDATE: info gathered from the Klipper Discord: this is a known thing on clone stm32 chips and temp mcu. Apparently the SV06 is not using an stm32 but a gd32. Apart from displaying the mcu_temp Klipper doesn't do anything with it, so according to feedback in the Discord there is no loss of safety features by not having the mcu_temp section in cfg.
Ah what a pity. Thanks for the hard work looking into this. Please consider pasting links to where you asked about this and what info you found, in case someone wants to look into this in the future.
I've recently installed Klipper on the SV06 (using KIAUH and the provided cfg files and firmware in this repository - Klipper install is on an OG RPi4). But I ran into the issue that when I added the mcu_temp readout in the cfg file, it would read as -409°C in Fluidd. That is way outside the limits (including those of the physical world), causing the printer to shut down. My other 2 printers (not SV06), that run from the same RPi4, did not have this issue.
Rebooting Klipper and/or the printer didn't change anything. Only commenting out the mcu_temp section again would allow me to actually control the printer. The code I used to activate the mcu readout was:
Klipper, Moonraker and all OS packages were updated to the latest versions (on 05/11/2023). Based on a hunch from a friend, I manually compiled the firmware again via Klipper, flashed that, and it solved the problem. So any users using the 'old' firmware in the misc folder might see the same issues pop up if they add the mcu_temp section to the cfg file when using newer versions of Klipper.
I would suggest either removing the firmware file, or providing an update of the firmware, compatible with the latest version of Klipper.
Image below shows the readouts in Fluidd. The jumps to 0°C are at the timestamps of firmware restarts.
After compiling new firmware, using the settings below, and flashing it to the printer, all worked as normal again.
Output after flashing new firmware: