search

rootiest / zippy-klipper_config

Zippy Klipper Config
GNU General Public License v3.0
383 stars 43 forks source link

TEST_RESONANCES lead to "Timer too close" error #7

Closed qratz closed 1 year ago

qratz commented 1 year ago

So i have been running a few test prints on my v0 using SKR Pico as CAN bridge, an EBB36 and a Pi3b. Everything is reliable so far, but the resonance testing. The test starts fine and works until ca. 100Hz and than crashes klipper with a "Timer too close" Error on the mcu (SKR Pico), not the pi nor the ebb36. Did you experience something similar? I am wondering if during resonance testing maybe the SKR Pico's 3.3V supply gets overloaded by the CAN adapter, which i supply from that.

rootiest commented 1 year ago

I have never personally had an issue with the input shaping tests but I have heard of others having that issue with a similar setup on a Octopus board, and with that BTT U2C board.

I'm not sure of the cause, but personally I don't think it's actually caused by a limitation of the USB-CANbus firmware but rather something else (although CAN related)

What speed are you running the CANbus at?

You could try increasing/decreasing the speed. This will require re-flashing all your canbus devices to match though.

qratz commented 1 year ago

Alright I have recompiled and flashed everything with a can bus speed of 1000000 and now input shaper calibration works perfectly fine. With 500000 i had a reliable "timer too close" crash.

rootiest commented 1 year ago

Awesome!

Maybe I should update the guide to use that speed instead..

I don't think there's any good reason not to.

Ironically the EBB36/EBB42 manual says to use 250000 which seems really slow to me.

rootiest commented 1 year ago

I'm going to close this because unfortunately TTC errors are more complex than can be addressed here.

At this time there is still not a clear solution for all cases but using a more powerful host system and a PREEMPT kernel will prevent this issue in a majority of cases.

With a raspberry pi 3 a 32-bit OS without PREEMPT is best. With a raspberry pi 4 or Intel system a 64-bit OS with PREEMPT is best.

TTC errors are caused by timing issues on the host system. There is a narrow window for can data packets to remain in sync and although klipper requests a high process priority, it can still sometimes be overtaken by other processes and cause these timing errors.

Another setting to try messing with is txqueuelen in your can0 file.

If yours is 128 or less, try increasing it to 1024.

If it is 512 or more, try decreasing it to 128.

Additionally, make sure your canbus network is not showing a large number of bytes_retransmit or bytes_invalid.

The bytes_retransmit are packets sent from the host that failed and had to be resent.

The bytes_invalid are packets sent to the host that failed and had to be resent.

If a universal solution to this issue is discovered, I will update my guides to reflect that.