Closed chuckwagoncomputing closed 1 week ago
It looks like this ticket is a request for help (or similar). Many helpful people will not see your message here and you are unlikely to get a useful response. Instead, see the contact directions at: https://www.klipper3d.org/Contact.html
We use github to share the results of work done to improve Klipper. We don't use github for requests. (In particular, we don't use github for feature requests, to answer questions, nor to help diagnose problems with a printer.)
Please follow the directions at: https://www.klipper3d.org/Contact.html
This ticket will be automatically closed.
Best regards, ~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being.
We do not use GH to discuss such topics. Please refer to above link.
Did you read it? This is not a request for help, a feature request, a question, or a request for diagnosis. I found a firmware bug, and presented a solution for comment. Would you rather I open a pull request with my half-baked fix?
I have been Mildly Annoyed, and decided to do something about it.
I have been having the same issue as some other folks: @viesturz Cosmin Not sure if the same issue, but seems likely
In short, when using a SB2209 CAN bus toolhead board, when restarting Klipper with
RESTART
, the extruder temperature is reported as a very large number, either negative or positive, before returning to normal over the next ~10 seconds. This doesn't happen all the time; it's pretty random.Here is the cause as well as I can understand it:
thermocouple_result
commands, because it wasn't restarted.thermocouple_result
command is sent before clock sync finishes,SecondarySync
'sclock_adj
still has 1 for the mcu frequency, which results in spi_temperature.py's_handle_temperature_response
getting an undivided value from its call toclock_to_print_time()
.thermocouple_result
command after clock sync has finished,temperature_callback
in heaters.py will multiply the difference in temperature by the difference between the undivided value and the new correct value, resulting in a very large "smoothed" temperature, either negative or positive depending on the direction of the temperature change.On my machine, I implemented the following fix:
In
_handle_spi_response
in spi_temperature.py:I'm not sure if this is the appropriate fix, as this is the first time I've touched the Klipper codebase, but I rather doubt it. It feels like something more fundamental should change, like maybe
clock_to_print_time
should throw an error if the clock isn't synced.