Printer Model: Voron Trident
MCU / Printerboard: Octopus Pro 1.0
Host / SBC - PI 3b
klippy.log klippy.log.zip (3.5 MB)
I know that this issue has being discussed a few times, but I was not able to find a solution for that. Until two months ago I was running my Trident with a BTT SKR 1.4 without no issues, but then I decide to upgrade the motherboard to an Octopus Pro 1.0 and install an EBB SB 2009 on the tool head. Since than I have random printing issues related to the title. My version of klipper installed into the machine is the last one - v0.12.0-378-gd6494ffe.
In short prints the problem does not appear, but in the long ones the issue appears with no warning and can occur at the beginning, middle or close to the end which I think do not show any standard of behaviour.
Is someone have found a definitive solution for this kind of issue?
A “Move queue overflow” error is rare. It is typically related to micro-controller clock synchronization problems. You can take a look at Advanced Trouble-Shooting / Graphing Klipper for some hints on debugging clock synchronization. Unfortunately, I don’t have much additional help I can offer. Note that you’ve modified the Klipper code (at a minimum, some additional code has been added to the extras directory) so it is also possible one of those changes is impacting the system. It’s also possible it is hardware related (for examples, problems with voltages or problems with crystals on the host and/or mcus) - you could also try following the steps at Timeout with MCU / Lost communication with MCU
Hi Kevin. Thanks for your repply to my question. I did a whole check of my machine configuration and found out that my TransmitQueueLength was pretty much higher than the 128 recommended. It was setup to 1024. Maybe the higher value is nothing related to the problem but I will give a try with the lower recommended one. I will check as well both links you advise too. If I find something different that other people have found I will publish here.
I may have found the issue I was facing in my printer. When I installed the new boards, I used the Mainsail OS 64 bit version as the basic installation of my PI. Today, atfer I had done a clean install of my printer OS I choose the debian lite 32 bit version and reinstall everything else. The printer now is operating flawlessly. Apparently the problem was the 64 bit PI operation system. If someone else is facing the same issue and is using PI OS 64 Bit try to reinstall with a 32 bit version. It may fix the whole issue related to queue overflow and other MCU communication errors
Hi Coro. No, not at all. After the new installation with the 32 bits version of Debian I didn’t receive any messages related to MCU communication errors. I also installed other printer iwth Mansail OS 32 bit version and everything is working fine
Ok, I’ll try 64 bit, if I experience problems again I’ll try 32bit.
I think my error was caused by tmc auto tune, which I uninstalled. It took me a while to figure out, and I figured it out about 30 minutes ago.
Ok, I was advised to uninstall TMC Auto Tune. I’m getting serious error messages, like my stepper driver, which controls the extruder motor, running too hot.
If you want to use TMC Auto Tune, remember to disable it after it has calculated the values you need.
TMC Auto Tune doesn’t seem to be something that is actively maintained. I bought the printer used and haven’t installed anything myself, so I’m planning to do a fresh install. Along the way, I’ll figure out what’s causing all the errors. So far, it seems to be all the modules that aren’t officially supported by the printer, except for Shaktune, which doesn’t generate errors. However, I recommend not using Shaktune’s auto function.
The CAN-bus cable also seems to be quite long, and my multimeter is in a distant warehouse. This could also be the reason I’m getting all the error messages and why the printer crashes in the middle of a print.
I’ll be done in a few hours and can provide a report later today or tomorrow on how it worked.