Printer: K1 MAX
MCU and SYSTEM information: see images i posted on imgur
Klippy.log is attached
Describe your issue:
At the end of the prints, the K1 MAX printer invokes a shutdown. It’s common to be called by the MCU “rpi” and it does not happen everytime!
This is a line that appears everytime, it can be seen in the “klippy.log”.
[mcu:_handle_shutdown:618] MCU ‘rpi’ shutdown: Rescheduled timer in the past
I was reading about in the log and it seems something related to the step rate of the steppers. As stated in this topic below,
I attached an image showing all system MCU’s and after this shutdown happened i started another print and generated an image of the system page with all the loads in each MCU, “MCU RPI” shows an abnormally high load, like 200%.
In the print i stated above, i watch for a couple of hours the system page and i noticed this,
MCU load shows 2.28% and this is seens to be normal;
Klipper load it’s always above 130%, this does not seen to be ok;
MCU RPI load it’s always above 200%, this does not seen to be ok;
System load shows a value always above than the limit of the 2;
Could the load of MCU RPI be related to those shutdowns?
How to diagnose it and any idea how to approach this problem?
I am new to klipper and if anyone can shine some light into this issue i would be very happy.
Klipper is a free product and all that is asked for is to comply with its license and make any modifications to its source code public.
Creality chose to:
Modify Klipper and NOT make the modifications public
Has never attempted to bring anything back to the community or to contribute to improving Klipper main line
Has crippled the klippy.log so that the common strategies or tools to analyze it are no longer working
This community is only actively supporting Klipper main line. Hunting for errors that might be caused by some of the closed-source modifications for printers that do not even follow a minimal sense of decency, seems like badly invested time.
Please revert directly to Creality for any support requests.
Sineos, i understand that already from the first post.
I have invested money on this printer, cannot return it. I am asking for help to start the troubleshooting on my own, what would be the common approach so i can try it, like hearing from advanced users what should i look for or try for.
You’re not helping Creality by helping me, you’re helping an user that has tons of printers running klipper and is well aware of the importance of Open Source in this community.
Look, even if I would choose to ignore Creality and help you, because you are just a nice guy with an issue, I could not even meaningful support you:
This machine uses hardware I do not know
Settings in its printer.cfg I have not even the faintest idea what they are doing
Shows a Klipper behavior that does not match the behavior of the “original” Klipper
Your issue for example:
It seems that the error has been caused by the [mcu rpi], which I have not seen in years before and which also seems to make no sense.
Also on a first look it seems that the error happened after the print has finished, which also makes no sense for this kind of error.
Have you looked any the loads in the system? Is this normal? Are there a benchmark somewhere where i can look to create a pattern to find this error?
About the “Rescheduled timer in the past”, i tried to look in the klippy.log, but it seens different from the phrase on your post, may that be because of Creality changes?
That approach in the same post about graphing the behavior would be useful or the images of the system load speak for itself?
From the screenshots it seems that the host is a 2-core CPU. With this assumption, a system load of >2, respectively >210% is definitively too high and would indicate an overload condition (original Klipper reports its load scaled to 1 core, so a 4 core CPU can go up to 400%).
The graphing tools of original Klipper will not work with the modified logs and it contains a lot of stuff, I have no idea what it means.
I’m sorry if I missed something. But why not just root the printer and install “genuine Klipper”. If the OP has experience with Klipper, go with something that can supported here.
As far as I am aware you do not get genuine Klipper but only the option to mess up your installation a bit more and cause more incompatibilities than there had been before.
This machine requires Klipper modification to control its hardware and they never bothered to cooperate with Klipper but instead opted for going closed-source.
The biggest risk for the users thus is: Should they choose to EOL this printer, then you are likely stuck with an EOL’ed Klipper as well.
and pick up his Helper Script. This makes installing Klipper with Mainsail and/or Fluid very easy. I have installed
Klipper on a K1 a K1C and a K1 Max with no problems. The installation comes with about two dozen macros that simplify many of the tasks one would want with most any printer or on a Raspberry Pi. There are a whole raft of YouTube videos on how to install the stuff.
It is still my firm understanding that it will allow you:
To get root access to the Linux part
Install additional parts from the Klipper ecosystem, like web-interfaces etc.
It will not allow you:
Change of the Klipper firmware on the printer board(s) - at least not to the Klipper main-line
Change of the Klipper host application on the host SBC - at least not to the Klipper main-line
The Klipper core is and remains Creality with all its consequences. The only “way out” would be some interested developer who reverse-engineers the Creality changes and ports them over to main-line Klipper or a public Klipper fork that is then maintained as a community effort.
