[BUG] "Rescheduled timer in the past" in Klipper, meaning board don't keep up

[inOut47]

Description

During a print using Klipper firmware the print stops and an error is raised saying:

MCU 'mcu' shutdown: Rescheduled timer in the past
This generally occurs when the micro-controller has been
requested to step at a rate higher than it is capable of
obtaining.

From looking around on Klipper discord it looks like an issue alot of BTT E3 Mini meets. my configuration is pretty standard, 16 microstreps on all motors and a rotation distance of 40 on the X and Y axis, 2 on the Z and 32.448 on the E motors.

The board shouldn't choke with those settings.

Steps to reproduce

i cannot reliably reproduce, however this happens on only 1 board (i have a total of 3) and its pretty random. usally at first layers (this time it was literally on the first layer)

Expected behavior

Print finish to the end

Actual behavior

Print stopped mid first layer

Additional Information

klippy.log

[Zandhoeg]

Got the same issue. Get it randomly. Most of the time this comes along with this line

shutdown: Rescheduled timer in the past
clocksync state: mcu_freq=64000000 last_clock=133798147837

So klipper and board do not sync up properly?

[Macsbig]

Yes, me too. I have it on two Mini E3 V3 boards. It appears to be just random, can be early in print or near the end (had it 11 hrs into a 12 hr print, grrrrrrr). Sometimes I might not get it for a couple of days. Posted my Logs on the klipper Discord forum, and they couldn't see anything obvious. Damn annoying tho!

[Macsbig]

Out of interest, are you guys connected by the UART2 connection, or USB? I'm UART, and am wondering whether the USB connection might be more stable on this board? 🤷‍♂️

[Zandhoeg]

Out of interest, are you guys connected by the UART2 connection, or USB? I'm UART, and am wondering whether the USB connection might be more stable on this board? 🤷‍♂️

I am connected with UART2, but I started using it with USB and got the same issue there, that was why I swapped over to UART. One thing I seen is that the default profile uses 115200 baud and the klipper one uses 250000, not sure that affect anything other than potential reliability of transfer. But my logs all have issues where the clock seem to de-sync and not know what is sent when and/or think it done what been asked etc.

[inOut47]

Out of interest, are you guys connected by the UART2 connection, or USB? I'm UART, and am wondering whether the USB connection might be more stable on this board? 🤷‍♂️

it happend on USB so i switched to UART to try, happens just the same.

a nother intereseting thing is that i recently updated Klipper firmware to latest and i havn't expirienced another crush yet. might be ralted to a software bug on klipper side?

@Zandhoeg which version of klipper firmware are you running?

[Macsbig]

Interesting. I reinstalled mainsailOS and the firmware on the SKR board as I first experianced it a few weeks ago after updating mainsail/moonraker/klipper/Linux through Mainsail's built-in update manager. Doesn't seem to have helped tho, which is hard to figure.

[Zandhoeg]

@Zandhoeg which version of klipper firmware are you running?

I run FluiddPi 1.17 with whatever version of klipper that got. I did a update on everything and fluidd 1.18 got other errors so I didn't update again as I thought I had a stable system, until I got it again twice.

But I will check what version I got and also update (if able) and see if that does anything. Thing is I got the card like 2 weeks ago and had one early on, then the other and then not one for almost 1 week, until yesterday. And then I had done some calibration so the printer had been standing idle for long periods of time, done some homing, then idle, then a small print, idle etc.

[inOut47]

Try

Interesting. I reinstalled mainsailOS and the firmware on the SKR board as I first experianced it a few weeks ago after updating mainsail/moonraker/klipper/Linux through Mainsail's built-in update manager. Doesn't seem to have helped tho, which is hard to figure.

update klipper run make clean make and reflush the firmeware.

check it it says in the logs that the firmware have 120~ commands (my old one had 97 or something like that).

[Zandhoeg]

@Zandhoeg which version of klipper firmware are you running?

FluiddPi install image and what I am currently running;

fluidd
v1.17.0

Klipper
v0.10.0-278-g7c964e5f

moonraker
v0.7.1-428-ged20223

strange thing now is that klipper say (in the UI) it is up to date but I didn't update it... trying to see if there is a way in SSH to verify what version I got.

[Macsbig]

Try

Interesting. I reinstalled mainsailOS and the firmware on the SKR board as I first experianced it a few weeks ago after updating mainsail/moonraker/klipper/Linux through Mainsail's built-in update manager. Doesn't seem to have helped tho, which is hard to figure.

update klipper run make clean make and reflush the firmeware.

check it it says in the logs that the firmware have 120~ commands (my old one had 97 or something like that).

Thanks for the suggestion, but I did triy all of that. Machine ran flawlessly for months after I built it. Then I had issues so I tried all you suggested above. I even tried the BTT precompiled UART firmware...same results each time. Even tried a new board (reloaded everything agian - including new RPI Mainsail Image) made no difference at all. Printer is running this morning - and in 3 hours (short small <20min jobs running) and its not error'd once. It is very odd indeed.

Thanks

[Zandhoeg]

check it it says in the logs that the firmware have 120~ commands (my old one had 97 or something like that).

how/where do you check this? klippy.log or somewhere else? a make-log?

Also a general question. What machines do you run this on? What motors? and what RPi versions? I only got my error once during a print, but multiple times during extrusion calibration with a BMG extruder.

[Macsbig]

In fairness having just checked again the Klippy Log is showing this...

Loaded MCU 'mcu' 91 commands (v0.10.0-291-g4ce2d379 / gcc: (15:9-2019-q4-0ubuntu1) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] binutils: (2.34-4ubuntu1+13ubuntu1) 2.34) MCU 'mcu' config: BUS_PINS_i2c1=PB6,PB7 BUS_PINS_spi2a=PC2,PC3,PB10 BUS_PINS_i2c1a=PF1,PF0 RESERVE_PINS_serial=PA3,PA2 BUS_PINS_spi1a=PB4,PB5,PB3 STATS_SUMSQ_BASE=256 RECEIVE_WINDOW=192 STEPPER_BOTH_EDGE=1 SERIAL_BAUD=250000 ADC_MAX=4095 BUS_PINS_spi3=PB4,PB5,PB3 BUS_PINS_spi2=PB14,PB15,PB13 BUS_PINS_spi1=PA6,PA7,PA5 RESERVE_PINS_crystal=PF0,PF1 MCU=stm32g0b1xx CLOCK_FREQ=64000000 Configured MCU 'mcu' (1024 moves) Args: ['/home/pi/klipper/klippy/klippy.py', '/home/pi/klipper_config/printer.cfg', '-I', '/tmp/printer', '-l', '/home/pi/klipper_logs/klippy.log', '-a', '/tmp/klippy_uds'] Git version: 'v0.10.0-368-g4a8a76ea' CPU: 4 core ARMv7 Processor rev 4 (v7l) Python: '2.7.18 (default, Jul 14 2021, 08:11:37) \n[GCC 10.2.1 20210110]' =============== Log rollover at Sun May 1 07:53:57 2022 =============== Unable to issue reset command on MCU 'mcu' webhooks client 1970857864: Disconnected Restarting printer

So What does this mean, and how can I address it?

I am running an Ender 3 max with standard steppers etc. RPi 3B

[Zandhoeg]

Unable to issue reset command on MCU 'mcu' webhooks client 1970857864: Disconnected Restarting printer

is it this that you are missing under the [mcu] maybe?

restart_method: command

If not I have no idea. If using UART, maybe a cord is loose or not attached properly?

[Macsbig]

Sorry, think I sorted that issue, I was looking more at the

Loaded MCU 'mcu' 91 commands (v0.10.0-291-g4ce2d379 / gcc: (15:9-2019-q4-0ubuntu1) 9.2.1

That was suggested?

[Zandhoeg]

I had 94 on mine.

[Macsbig]

@inOut47 said theirs read ~120 and to check. I'm not sure what this means personally, but reported the findings with hope it may help solve our issues

[iwm911]

When you update klipper it obviously not updating the firmware.

Mine says ~120 commands on the mcu line after the firmware update.

After that errors went away so far (a week or so).

My machine is a custom build with simple extruder like the ender 3 one.

[Zandhoeg]

++edit++ re-doing the flash on the MCU after changes and reboot to see if that makes a change.

So far so good.

[Fraxul]

This should now be (correctly) fixed in https://github.com/Klipper3d/klipper/commit/3796a319599e84b58886ec6f733277bfe4f1a747 . Update Klipper to latest master and build/flash the firmware.

[inOut47]

Amazing, thank you all guys!

[brendandebeasi]

I am still having this issue, running the latest klipper, etc etc etc

[iwm911]

Did you reflashed you mcu?

On Mon, Dec 12, 2022, 07:02 Brendan DeBeasi @.***> wrote:

I am still having this issue, running the latest klipper, etc etc etc

— Reply to this email directly, view it on GitHub https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/issues/667#issuecomment-1345879844, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARSAUCOIP4MICD5DVAHDHDWM2WVXANCNFSM53ZTFXPQ . You are receiving this because you commented.Message ID: @.***>

[brendandebeasi]

@iwm911 Yes. I was using the officially provided klipper firmware, which is almost 9 months old :-/ This resolved the issue Filed an issue to update it. https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/issues/703

[cartesian-theatrics]

I'm still having this issue, albeit rarely (about once a week with heavy usage).

klipper v0.11.0-86-g6026a99a

moonraker v0.7.1-807-gdb81607

klipper.log

[daVid0n]

hey guys, i am facing the same issue since around 2 years now, from time to time it occurs and then i am without any error for weeks or months, but now it seems to have manifested and i cant print since weeks already.. For me, most of the time this error results in the CR touch throwing a random error, which usually gets ignored via the code line "probe_with_touch_mode: true", but this wont help any longer, the touch pin hangs and throws the error when homing - i did realize that sometimes, while the pin hangs, when I bend the wires, it works again... That is why i kept searching for mechanical issues, changed the board, the entire cabling, reflashed fimrware, switched the raspberry, switched the sprite extruder, set up new compiled and "original" klipper firmware.. nothing works until now.

And today the printer even threw the "rescheduled timer in the past" error.. which pointed me once again to this thread, desperately searching for THE solution to all my problems. Another hint to a synchronization issue is that sometimes, the printer has bufferiung issues and pauses after each layer.

So..... what is the solution to this? There must be someone, at least at BTT who should know what to do exactly. Please? :)

[Macsbig]

Hi DaVid0n

Rebuilding the firmware from yhe new version of Klipper, and reflashing the BTT board with the new firmware sorted it for me. Think I used discord in the end, and someone explained it better for me to understand. I havent had my issue since I last posted on here.

Hope this helps

Mark

[daVid0n]

thank you very much for your quick reply!! Ill try to find out how to update my mcu, i just cant find a description i can understand, and discord does not work for me, the link from btt seems wrong. Are you in their discord? Could you invite me plz?

[Macsbig]

I'm not really discord literate sorry. This was quite some time ago. Just start again, as you did when you put Klipper on your RPi and Skr mini. Go through the steps, one of which is flashing your BTT board. Let me know how you get on.

Mark

[daVid0n]

thx again, i compiled new firmware out of newest klipper and this updated my mcu version. Now it feels better to have both up to date. But I already saw the same error with the BL touch again, "failed to verify sensor state" .. seems this is still another issue, but hopefully syncing is fixed now, ill give an update if not

[Macsbig]

👍

[YosypC]

Any solution beside compiling Klipper from scratch? I've updated to the latest software.