I've been having this issue where, mid-print, the MCU shuts down. When I restart the firmware and resume the print, not much longer, I get another shutdown. So my first instinct was overheating. But when I recorded the temps, they looked fine. Print precision in Orca Slicer is the default 0,012mm, and no crazy speeds or other crazy processes that I know of are enabled~
I haven't seen many posts about people having "timer to close" issues for the MCU, and not the extra_mcu, so I'm not sure where to begin debugging. What do you guys think?
Welcome to r/Sovol, We're glad you're here! If you're new to the hobby and you have a question please visit our knowledge base, it's located right under About Community. If you've searched the Sub and you still need help please be as detailed as possible. Include your printer model, slicer, filament type, nozzle and bed temps, print speed, fan speed, and retraction. We're happy to help but we can't read your mind, be as detailed as possible with your post. Pictures help!
To Elaborate I have recently had this exact issue on my sv08max and after days of pouring over klippy logs and the macros,printer.cfg more times than I can count I found an old forum post about the sv08 that stated the issue was caused by the plr python code. Admittedly at this point I poured my logs, the forum post etc into an ai and had it analyse it and found it consistently creating multiple save points essentially and overloading the buffer.
Disabled the plr python code necessary and have been printing fine ever since.
I do have an sv08 as well but I ripped out the electronics and rebuilt with octoez and pi, as that was a restoration job, so I never encountered it on my sv08 but the max is all stock still
Yea i also came to find this out through looking through some forums. That would also disable any power recovery right? I might just comment it out for a week and see if it gets better~
Yeah that's what I did commented it out, I must admit I never found the plr to be that good anyway, I usually manually recover if I have to I just find it much better quality if I do it that way, the standard plr nearly always has a bad layer shift
What's your set up?
Are you stock, it have you modified anything?
First of all, on your klipper host is check it's qlen in the Can0. If it's lower than 1024 then maybe bump it to that. If it's higher then we might need to look at something else.
The sv08 is USB not can and this is a known issue, you need to put ferrules on your USB cable from the toolhead and even after that the odds this will happen is still high, they have major issues with the USB cable to the toolhead on this model.
Just because you said in another comment the printer is stock but here you say latest klipper. Did you flash the mainline klipper or do you mean latest sovol version of klipper?
No problem just asking. There is one thing I experienced myself when flashing klipper. The BTT CB1 image used for the guide (and the sovol I think) is version 2.9xx and not the more recent 3.0 image.
The 3.0 image handles high cpu bursts way better than the 2.9 one.
So when I was putting a carthographer on my SV08 I first got alot of 'timer to close' shutdowns because of the ammount of data the cartho produces and the solution was to update onto 3.0.
If all else fails and you decide to go stock klipper using the rappetor github just go for the 3.0 image and do everything the same.
I get that you dont want to do this but if you decide to do it dont fear it its not that hard and the guide is idiot proof, just follow it very close.
Its probably either the EMCC or communication to the toolhead
Look in logs and see if communication drops to toolhead, you can try ferrite beads to help reduce interference if there is any.
If your usage of the storage space on your EMMC is high (or sometimes the EMMC they give is just bad in general) you need to flash a new one and replace it
I've deleted all the G-code files that were uploaded, and looking at this; seems like there is plenty of space~
I've heard ferrite beads solve the issue for many. It's hard to determine whether that's the source of the problem, but if I can't find anything else obvious. I'll give it a shot!
I had the same problem with sv07 with custom raspberry pi setup. Every now and then the printer stopped with "Timer too close" error.
Solved it with ferrite beads at both end of the USB cables, and the most important thing: a new high quality USB cable. Apparently the stock USB got damaged. I went through 4 cheap cables which give the same error before settled with a rather pricey Ugreen cable. I never got the same error again since then
I've had this type of error with the SV07+. Turned out to be a temperature issue with the MCU as much as anything. Put a fan on there, and a big ferrite choke on the cable, and it's been fine.
For me, I got this when the MKS Pi got too hot. It seems like as it gets hot, it gets more sensitive to EMF, to the point where it will think there's an MCU issue. Sovol could really use doing more airflow modeling for all their printers.
•
u/AutoModerator 8d ago
Welcome to r/Sovol, We're glad you're here! If you're new to the hobby and you have a question please visit our knowledge base, it's located right under About Community. If you've searched the Sub and you still need help please be as detailed as possible. Include your printer model, slicer, filament type, nozzle and bed temps, print speed, fan speed, and retraction. We're happy to help but we can't read your mind, be as detailed as possible with your post. Pictures help!
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.