Printer Model: VORON 2.4 350mm CANBUS USB
MKS skipr whit THR36 connected whit USB
klippy.log
klippy.zip (3.9 MB)
Hi guys, I ran a 16h print yesterday but unfortunately it failed about halfway through with this error:
Do you have any idea what caused this?
Did you already check the forum search:
Of course yes I looked on this forum and on the internet I read everything I found.
But I wanted to know if someone could analyze my klippy file to see if something had happened before this error. I’m going to do some tests on my side but this error really has many possible causes. I would like to know a little about where find out if it is possible.
Maybe people who happened to
Apart from the information given in the link @LifeOfBrian has already provided, there is not much you can get from the log. It is the only error in your log.
Oh very good then!
I relaunched the same 16h print (but without filament) overnight and it just finished perfectly…
Yesterday before restarting the second print I looked under the printer and I saw that the temporary fan that I had installed while waiting to print the skirts had fallen and nothing was cooling the motherboard anymore.
Maybe the problem came from there or maybe it will happen again randomly I’ll see
Well, I still had errors: MKS_THR timer too close…
Does somebody have an idea?
Do you think if I try to connect via CAN that will solve the problem?
I presume this is the thread that you were talking about elsewhere.
I’ve been watching it but don’t have much to add other than my usual question in this case; what is your host system?
From what I’ve seen here, “Timer too close” is generally an issue when somebody is using a marginal or inappropriate host for their system.
I always recommend a Raspberry 4B as the first selection of a host with a CM4 being a close second. I have had good results with a CB1 but I find it to be more fussy to work with than a CM4 (although it’s a lot cheaper at this time). I don’t believe I have ever seen a “Timer too close” problem with these hosts, although there could be somebody out there that has experienced issues with them.
Other SBC hosts, such as the Pi Zero seem to be more likely to have timer too close problems. This doesn’t mean that people can’t get them to work and don’t have success from them, just that I see them flagging problems.
Using an old laptop that has been converted to Linux is often problematic. This doesn’t mean that people haven’t had success with them but it’s often a lot of work to properly clean out all the background processes which can cause a delay in Klipper communications and still have a functional system.
I’m sure there are a lot of people who are watching this thread and will respond when something new comes up. Please post questions on your own thread and don’t attempt to hijack others.
Mz motherboard is an MKS skipr as I specified in my first message
And in the other discussion I wasn’t asking to solve my problem but only to know if people using the “normal” CAN had this kind of problem, it’s different
Using canbus won’t solve the issue. Looking at the log its clear that Klipper’s main thread is being blocked.
Stats 106088.3: gcodein=0 mcu: mcu_awake=0.010 mcu_task_avg=0.000021 mcu_task_stddev=0.000029 bytes_write=119750548 bytes_read=30331152 bytes_retransmit=0 bytes_invalid=0 send_seq=2546400 receive_seq=2546400 retransmit_seq=0 srtt=0.002 rttvar=0.001 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168004476 MKS_THR: mcu_awake=0.004 mcu_task_avg=0.000011 mcu_task_stddev=0.000015 bytes_write=35233018 bytes_read=9233430 bytes_retransmit=9 bytes_invalid=0 send_seq=750770 receive_seq=750770 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=12014277 adj=12013932 rpi: mcu_awake=0.000 mcu_task_avg=0.000008 mcu_task_stddev=0.000016 bytes_write=356442 bytes_read=1099333 bytes_retransmit=0 bytes_invalid=0 send_seq=59383 receive_seq=59383 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=50000007 adj=49998743 heater_bed: target=120 temp=119.9 pwm=0.441 enclosure: temp=36.8 sd_pos=24425732 sysload=1.19 cputime=10570.354 memavail=398972 print_time=58387.882 buffer_time=2.123 print_stall=0 extruder: target=240 temp=241.1 pwm=0.180
Stats 106089.3: gcodein=0 mcu: mcu_awake=0.010 mcu_task_avg=0.000021 mcu_task_stddev=0.000029 bytes_write=119753856 bytes_read=30331839 bytes_retransmit=0 bytes_invalid=0 send_seq=2546468 receive_seq=2546468 retransmit_seq=0 srtt=0.002 rttvar=0.002 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168004465 MKS_THR: mcu_awake=0.004 mcu_task_avg=0.000011 mcu_task_stddev=0.000015 bytes_write=35234056 bytes_read=9233633 bytes_retransmit=9 bytes_invalid=0 send_seq=750790 receive_seq=750790 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=12014274 adj=12013903 rpi: mcu_awake=0.000 mcu_task_avg=0.000008 mcu_task_stddev=0.000016 bytes_write=356448 bytes_read=1099349 bytes_retransmit=0 bytes_invalid=0 send_seq=59384 receive_seq=59384 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=50000007 adj=49998777 heater_bed: target=120 temp=119.9 pwm=0.587 enclosure: temp=37.0 sd_pos=24427402 sysload=1.19 cputime=10570.465 memavail=403568 print_time=58389.062 buffer_time=2.302 print_stall=0 extruder: target=240 temp=240.7 pwm=0.405
Stats 106092.9: gcodein=0 mcu: mcu_awake=0.006 mcu_task_avg=0.000019 mcu_task_stddev=0.000029 bytes_write=119756332 bytes_read=30332737 bytes_retransmit=0 bytes_invalid=0 send_seq=2546528 receive_seq=2546525 retransmit_seq=0 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=1225 upcoming_bytes=129 freq=168004480 MKS_THR: mcu_awake=0.004 mcu_task_avg=0.000010 mcu_task_stddev=0.000015 bytes_write=35235351 bytes_read=9234005 bytes_retransmit=497 bytes_invalid=0 send_seq=750821 receive_seq=750812 retransmit_seq=750821 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=12014271 adj=12013895 rpi: mcu_awake=0.000 mcu_task_avg=0.000006 mcu_task_stddev=0.000013 bytes_write=356460 bytes_read=1099394 bytes_retransmit=0 bytes_invalid=0 send_seq=59386 receive_seq=59386 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=50000004 adj=49998791 heater_bed: target=120 temp=120.1 pwm=0.370 enclosure: temp=37.0 sd_pos=24428534 sysload=1.49 cputime=10570.602 memavail=403664 print_time=58390.221 buffer_time=0.000 print_stall=0 extruder: target=240 temp=239.0 pwm=0.600
MCU 'MKS_THR' shutdown: Timer too close
Klipper logs stats every second, you can see that it was blocked for nearly 4 seconds prior to the error. As mentioned, this is typically caused by an inadequate power supply, inadequate cooling, or a low quality sd card. Its also possible that some other task is running and gobbling up CPU time, however I think that is unlikely.
It could also potentially be caused by a kernel or driver issue. This is my biggest concern with these all in one SBCs. This board is running Python 3.7 which has reached EOL. You may want to see if there is an updated OS image for it.
Thank you very much Arksine!
I couldn’t understand my logs file.
If CAN is not going to solve my problem then I prefer to stay in USB I am satisfied with it.
Only this error disappoints me…
What cooling are you talking about? of the THR36?
Otherwise following your advice I will
-try another power supply (I got mine from my old printer which is over 10 years old…)
-try another sd card
-and try to update with these unofficial but updated versions:
Thank you for the suggestions I will let you know if it works if there are other things I can try don’t hesitate to tell me
What cooling are you talking about? of the THR36?
The CPU on the MKS skipr. If its overheating it is possible that its throttling and causing the issue. One of those heatsinks they sell for the Raspberry Pi may work, and it you can probably find a way to mount a fan to blow air across it.
Well it’s strange because I used the MKS SKIPR on my old printer (but without the CANBUS (THR36))
and I didn’t have this kind of error
a fan is already blowing on the motherboard
I will still add a radiator on the 2 cards
I also ordered the emmc to see if it comes from the sd
I added coolers to the processor of the mks skipr and improved ventilation and I no longer have a “timer too close” problem for the moment 
A little photo to show you
And I want to say that MKS was very motivated to help me so I wanted to say that
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
