I’m recently facing klipper stopping mid print. Actually more like first few layers. I have been using klipper well for past 3-4 months. I didnt update anything, and cant seem to point what the problem is:
I’m using both Mainsail and Fluidd on single Raspi, both run well for past few months.
Last week after a print, i get error on my heatbed thermistor (ADC out of range), then i replaced it.
After that, every print, it will stop after 3-4 first layer. I tried to continue by modifying gcode and worked for now, but i cant do bigger prints now.
I can’t really figure out what is wrong. Either is it klipper issue or hardware issue? If anyone can help diagnose some pointer that will be greatly appreciated.
It had stopped many times and I noticed two errors that happened but cant figure out the problem:
Got EOF when reading from device
Internal error on command:”G1”
Oh yeah, the other printer is running well with klipper, so i guess it is not the Raspi / klipper installation, more like what may go on my Ender 6,
Please if anyone can find a clue so i can try do something about it and have it fixed will be great. I cant print anything now and wasting filaments. I attached klipper and moonraker log along. Thanks in advance.
These are serious errors meaning that Klipper cannot longer reliably predict the MCU’s clock.
Potential reason could be a severely maladjusted clock on your host (e.g. RPi) with the Linux system trying to correct it.
Check your date / time and ntp settings
Also check with dmesg if there are any USB related errors
Omg. I frankly didnt understand much of what was said, but tried fiddling and synced the time using ntp (googled it). Ran my printer and so far, it hasnt stopped. Cross my fingers. Hopefully it will finish. I frankly can’t figure out the logic behind time sync causing it to stop, while my other printer is still running well. But so far so good. Thanks a lot @Sineos for the brilliant tip.
Wow. Just finished the whole 24 hour print. Wouldnt be able to figure that out. Thanks alot for the help @Sineos. Been spending whole week fiddling and you have saved the day. Much appreciated.
Typically you have NTP installed which should make sure that the time in your system stay synchornized with a atom clock time server
If the clock should, for whatever reason, be dramatically wrong, the NTP does usually not jump to the correct time but incrementally works to correct the time bit by bit
Klipper alyways compares the RPi clock with the MCU timing to stay in sync and schedule all necessary actions
Now if NTP is currently working to correct the clock, Klipper has no basis anymore to compare as the clock is different whenever Klipper checks it.
Make sure you have a proper setup NTP on your host and this error should not happen anymore. An initial clock correction can be done with the ntpdate command which also “jumps” the time.
Depending on the used distribution the more lightweight timesyncd can be used.
For all these tools and abundance of guides are available in the internet, e.g.
Just tried another print after and it happened again. I think i may not have done it correctly. I’ve attached the klippy log for that print.
What i don’t understand is, im running Mainsail and Fluidd on the same Pi. My other printer runs well on the Fluidd, The one that keeps having probs is the Ender 6 on Mainsail.
If it has nothing to do with the interface (Mainsail / Fluidd), instead its the clock on the RpI, why my other printer runs well.
Can you let me know in more layman terms, what do i need to sync (is the clock on rpi vs what?) and how do i check if its correct?
I’m sorry for these basic questions. Not very techy person but know a bit of logic and manage to run klipper for a while.
The “Resetting prediction variance” messages were likely due to poor ntp synchronization - but those messages aren’t relevant as they refer to the unused “rpi mcu” which wasn’t involved in the actual failure.
Ah ok. Thanks @koconnor for the clarification. Not sure which hardward part but that probably pins down the issue. Thank you for taking the time to answer. Love Klipper,
You can never rely on the system clock (the one that an NTP client would update) being correct. Synchronizing the mcu and the host MUST NOT be made using the host’s system clock!
Assuming python you would use time.perf_counter() or time.process_time() but never, ever, ever time.time(). An update of the system clock by the NTP client will not affect time.perf_counter() or time.process_time().
If the klipper sync code indeed is affected by a system time update then that is a severe bug. Please say it isn’t so…