Thanks for all your advice, I will give some stuff mentioned a try. Eventually when chips are affordable again I will pickup a Pi for my RatRig most likely.
If anyone else has any ideas, please share.
There’s an interesting thread developing under developers on understanding and troubleshooting timing issues:
I have researched USB issues on Proxmox/KVM and found there was a bug in QEMU that was causing VM freezups - something I have experienced with Pi PICO. Given that well working USB connection is crucial for Klipper I figured the best way would be to install cheap PCIe USB3.0 host adapter and passthrough the PCIe slot to the VM. I’ll report here how well that works (I don’t see why it wouldn’t).
I don’t know the details of the USB bug to tell if it could have been causing other issues than freezups, however I think PCIe passthrough could be one way to remove any thoughts about USB being the cause.
EDIT: just confirmed: passing-through whole PCIe sunrize xHCL controller to the VM, instead of individual USB port, bypasses the USB bug as expected.
If you look in the klippy.log file you’ll see “Stats” lines once a second during a print. Part of the line will look like: mcu: mcu_awake=0.034 mcu_task_avg=0.000028 mcu_task_stddev=0.000035 bytes_write=94552431 bytes_read=16958126 bytes_retransmit=604 bytes_invalid=0 send_seq=1707525 receive_seq=1707525 retransmit_seq=484586 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=42 stalled_bytes=0 freq=71997236. This is information on the mcu status. The srtt report is the smooth-round-trip-time, the rttvar is the round-trip-time-variance, and rto is the retransmit-timeout. Other stats there may also be of interest in quantifying the health of the connection.
-Kevin
EDIT: This info is also available internally in Klipper - see the last_stats variable in the “mcu” status reference: Status reference - Klipper documentation
Just a thought.
@w00sh is running Klipper with Fluidd in VM
@Print3DWorld is running Klipper with Octoprint VM
There are “some” known USB Serial issues with Octoprint that could be adding insult to injury. Maybe try running Fluidd or Mainsail I. Your VM and see if you get different results?
Good point. I have never run oktoprint so I cannot tell how well it works in VM environment.
To follow-up on my earlier post, after running few days with PCI passthrough of whole USB controller (instead of individual device) I believe that it should be a recommended configuration - it’s a noticeable improvement, USB of pi PICO is no longer causing issues to my VMs, and I don’t need to restart klipper as often to get going.
I have also tried mainsail and fluidd but octoprint was still enabled. I can try disabling it.
I disabled Octoprint and tried other things, but i keep losing prints halfway through. I am going back to marlin for now until I can “waste” filament testing more things. I cant keep losing hours and filament to half prints =*(
I really liked the way mainsail and klipper ran, and my VM should have plenty of horsepower for what is going on.
Did you try to pass-through whole USB controller?
Thanks for your help w00sh, but at the moment I cannot forward the whole USB controller as I have a zigbee device for my home automation on the same USB hub.
I think it’s worth trying when you can. Passing through whole USB controller solved all my issues - some I did not know I have (e.g. l had to restart klipper after turning the printer on, now it just connects).
Copy that, will give it a try once I can relocate my zigbee device. I shut down my other devices and servers during the winter due to power usage. Once it warms back up a little, I will probably go back to two servers and have more room.
I appreciate all your help. I still think there should be a way to desensitize the mcu timer, as my printer ran just fine and never had an issue other than that damn error.