Random Klipper Timer too close in v4.0.0

[Martin11180]

K-Shake&Tune module branch

• [X] I confirm using the main branch

Version

Shake&Tune v4.0.0

Describe the bug and expected behavior

I don't know if it's a bug or a setting problem When I run the COMPARE_BELTS_RESPONSES and then call Home or other functions there is a message in the console Unable to obtain 'spi_transfer_response' response

klipper Klipper meldet: SHUTDOWN

MCU 'mcu' shutdown: Timer too close

I delete your setting under Printer.cfg and run for example SHAPER_CALIBRATE one after the other it works How can I get back to the previous version to test whether it works?

BIGTREETECH Manta M8P V2 EBB 2209 / RP2040 TFT35 SPI V2.1 CB1 emmc board mcu EBBCan(rp2040)

Board und EBB neu geflasht mcu EBBCan(rp2040) Version: v0.12.0-230-g0d87bec1 Auslastung: 0.05, Wach: 0.22, Freq: 12 MHz, mcu(stm32h723xx) Version: v0.12.0-237-gfcf064ba Auslastung: 0.00, Wach: 0.01, Freq: 400 MHz, Temp: 44°C

Additional information and klippy.log

klippy.73.log

[godbnc]

i post yesterday same problem :) mcu timer to close:)

[drumstick77]

same problem here [Uploading klippy (1).log…]()

[Martin11180]

Does anyone know how to get the previous version running again?

[drumstick77]

not sure. myself... like they say....if it ain't broken....

[Martin11180]

@godbnc Do you have the current version installed and can do it a few times in a row, for example COMPARE_BELTS_RESPONSES

[Frix-x]

I'm aware of this issue. It's not solved at the moment but shouldn't be very problematic as the graphs are done in background and should still be generated correctly. So in the meantime, if the issue happens during the second axis (Y) measurement during the AXES_SHAPER_CALIBRATION macro, then just do only X, restart klipper and do Y to get both of the graphs generated.

I'm working on solving this. But the common point for people having this issue is running either a low powered pi clone like a BTT CB1 or a lot of things like CANbus, lot of neopixels, high precision stepper control from DK, etc...

[Martin11180]

Hello Can you explain how to get to de version 3.0.0 when I do it [Errno 18] Invalid cross-device link

[drumstick77]

I'm aware of this issue. It's not solved at the moment but shouldn't be very problematic as the graphs are done in background and should still be generated correctly. So in the meantime, if the issue happens during the second axis (Y) measurement during the AXES_SHAPER_CALIBRATION macro, then just do only X, restart klipper and do Y to get both of the graphs generated.

I'm working on solving this. But the common point for people having this issue is running either a low powered pi clone like a BTT CB1 or a lot of things like CANbus, lot of neopixels, high precision stepper control from DK, etc...

I tried this, doing X is fine. but not Y even after restarting klipper

[Frix-x]

Hello Can you explain how to get to de version 3.0.0 when I do it [Errno 18] Invalid cross-device link

The latest v3.0.0-x version is 56a5502d81a9071b1a40f5da4138f195eb6bf8ec -> you need to checkout this exact commit and then restart the install script manually from the folder (cd ~/klippain_shaketune && ./install.sh)

I tried this, doing X is fine. but not Y even after restarting klipper

This is very strange as it worked for all the people having this issue until now... Maybe a firmware restart is needed then? But that's would be even more strange...

[drumstick77]

ok, so for some odd reason, i just tried Y again and it worked. not sure what happened then. thanks for the suggestion

[drumstick77]

ah then after it finished calculating Y, I got the time too close error. So seems like I need to do another restart after Y. it seems to be a problem after doing Y and not X.

[Martin11180]

source "klippy-env/bin/activate" pip uninstall -r "./klippain_shaketune/requirements.txt" -y deactivate rm -d ./printer_data/config/K-ShakeTune rm -d ./printer_data/config/scripts/K-ShakeTune sudo rm -r ./klippain_shaketune/shaketune ./klipper/klippy/extras/shaketune sudo rm -r klippain_shaketune

git clone --branch v3.0.0 --single-branch https://github.com/Frix-x/klippain-shaketune.git klippain_shaketune install edit check_download to #check_download ./install.sh File "/home/biqu/klippain_shaketune/src/is_workflow.py", line 212, in create_graph lognames = self._move_and_prepare_files( File "/home/biqu/klippain_shaketune/src/is_workflow.py", line 173, in _move_and_prepare_files filename.rename(new_file) File "/usr/lib/python3.9/pathlib.py", line 1377, in rename self._accessor.rename(self, target) OSError: [Errno 18] Invalid cross-device link: '/tmp/raw_data_axis=1.000,-1.000_a.csv' -> '/home/biqu/printer_data/config/K-ShakeTune_results/belts/belts_20240616_175611_A.csv' Shake&Tune version: v3.0.0 Error while generating the graphs: [Errno 18] Invalid cross-device link: '/tmp/raw_data_axis=1.000,-1.000_a.csv' -> '/home/biqu/printer_data/config/K-ShakeTune_results/belts/belts_20240616_175611_A.csv' 19:56 Traceback (most recent call last): File "/home/biqu/klippain_shaketune/src/is_workflow.py", line 407, in main graph_creator.create_graph()

[Frix-x]

ah then after it finished calculating Y, I got the time too close error. So seems like I need to do another restart after Y. it seems to be a problem after doing Y and not X.

I pushed a potential fix on this branch: https://github.com/Frix-x/klippain-shaketune/tree/fix-timer-too-close Would you mind testing it please and tell me if it works? Don't forget to restart the klipper service after git checkout the branch to be sure you are running the latest version of the code.

[Martin11180]

I still did it that way MCU 'mcu' shutdown: Move queue overflow sudo rm -r ./klippain_shaketune git clone https://github.com/Frix-x/klippain-shaketune.git git checkout remotes/origin/fix-timer-too-close install edit check_download to #check_download ./install.sh

change to the file shaketune/shaketune_process.py can be seen

[drumstick77]

HUZZAH!!!! did it on one of my printers with success. M8P V1.2 with CB1. I have another with M8P V2.0 + CB1 and I will test this later as it's still printing. But it's looking good!!!! No need to restart, no errors!! Many thanks!!!!!

I will try the belt comparison and get back to you with updates as well. not sure if belt comparison was causing any issues as well.

[Frix-x]

Wow it seems promising! But due to the feedback of Martin just above, I pushed another commit (to get the accelerometer file writing into its own subprocess) like 3 min before your comment. Can you tell me if you are indeed using the latest commit or the one from one hour ago?

[drumstick77]

that's when I did the update. have I got the latest commit?

[drumstick77]

sorry just realise time stamp means nothing to you. LOL!!! let me work it out when exactly

[drumstick77]

so I did it; around 18/19 minutes ago from me posting this message. or probably best if you can tell me the command to check the version that I've got installed?

[drumstick77]

it's not showing on the update manager section of mainsail even though it's in moonraker.cfg

[Martin11180]

@Drumbe M8P V2.0 + CB1 Use an SD card or eMMC with these boards

[drumstick77]

I just updated my M8P V2.0 + CB1 Sd card version and still getting the same error after X and when it's about to start Y. My other one which is M8P V1.2 + CB1 is also the sdcard version

[jhorn70]

My python/linux experience is limited, I'm a dotNet guy. Should I be able to just check out the branch and do a firmware restart to test the fix?

[jhorn70]

I checked out the branch and verified it was there, restarted and it still occurred, but now, instead of timer too close the error is MCU 'mcu' shutdown: Move queue overflow. It occurs when the Y axis test begins after the file has been written.

For reference, I am running:

Pi 4B 2GB Beacon USB Screen USB Touchscreen EBB 42 toolboard

[delisjr]

ah then after it finished calculating Y, I got the time too close error. So seems like I need to do another restart after Y. it seems to be a problem after doing Y and not X.

I had the same issue. My system configuration:

Voron 2.4 BTT PI BTT Octopus Pro BTT EBB 2209 / RP2040 BTT HDMI 5''

I temporary removed removed _st_process.wait_forcompletion() from compare_belts_reponses.py and the process goes to the end. So, I modified shaketune_process.py following the code from gcode_shell_command.py to avoid process.join():

 def wait_for_completion(self) -> None:
        reactor = self._printer.get_reactor()
        eventtime = reactor.monotonic()
        endtime = eventtime + self._timeout
        complete = False
        while eventtime < endtime:
            eventtime = reactor.pause(eventtime + .05)
            if not self._process.is_alive():
                complete = True
                break
        if not complete:
            ConsoleOutput.print('Timeout: Shake&Tune computation did not finish within the specified timeout!')
            os._exit(1)  # Forcefully exit the process     

The problem is solved. I also integrated mods from and made a few changes to maintain compatibility with Klipper version < v0.12.0 (mainly related to (_toolhead_info['minimum_cruiseratio'] )

shaketune.zip

[Frix-x]

That's interesting, because that's what I did first, but it caused problems. So I switched to the standard "join()" method instead, and that fixed the problems on my machine...

Ok, so I think I'll work on switching it back to that while keeping the other improvements I've already put into the fix-timer-too-close branch. Hopefully we can find a way to make this work for everyone!

I also integrated mods from and made a few changes to maintain compatibility with Klipper version < v0.12.0 (mainly related to (toolhead_info['minimum_cruise_ratio'] )

Would you mind opening a PR for this? I'm interested to integrate this to everyone as well :)

[Frix-x]

So I just pushed a new commit to the branch. Hopefully it will now be fixed :)

[drumstick77]

just a quick update updated to V4.0.0.2 M8P V1.2 + CB1 SD Card version fixed M8P V2.0 + CB1 SD Card version and is still NOT fixed.

thanks

[Martin11180]

Hi Unfortunately not for me now I get it again MCU 'mcu' shutdown: Timer too close did it like that

wget -O - https://raw.githubusercontent.com/Frix-x/klippain-shaketune/main/install.sh | bash cd klippain_shaketune git checkout remotes/origin/fix-timer-too-close And now all results are under ShakeTune_results and not, for example, ShakeTune_results/Belts/ I think I'll switch to an SD card

OK, I guess I don't need it if drumstick77 has the SD card

[godbnc]

MCU 'mcu' shutdown: Move queue overflow Once the underlying issue is corrected, use the "FIRMWARE_RESTART" command to reset the firmware, reload the config, and restart the host software. Printer is shutdown

[Frix-x]

Please give me a corresponding klippy.log to make sure you are using the correct version? I have a lot of positive feedback on this branch that it fixed the problem, and I'm not sure if you're actually using the latest...

[drumstick77]

just kicking it off now. will attach log when done. but here's a snippet of the console

[Frix-x]

Ok, so I can confirm that you are indeed not using the fix-timer-too-close branch but the latest version from main. So it's normal then... You should see: v4.0.0-6-g9b0ff2c

So I will merge the current work into the main branch as it was already reported to fix the problem at most people :)

[godbnc]

Frix same here no use v4.0.0.6 :( thats i have error

[drumstick77]

sorry for the silly question but i ran the script as you have stated on your documentation but it has not installed 4.0.0.6 but seems like godbnc still has the same issue anyway with 4.0.0.6

[Frix-x]

Oh, that's normal, it's not pushed to the main branch for now as it's a testing version only available on the fix-timer-too-close branch. So you need to manually checkout this branch to be able to use it.

But it should not be a problem anymore, I'll merge it in like half an hour, I just need some time to do some final testing and cleanup the PR a bit.

[Martin11180]

Hi

It works for me now and I have completely turned off the printer But there is still the problem that all files end up in ShakeTune_results See photo

[drumstick77]

I second that, seems to now work ok on the M8P v2.0 CB1 sdcard.

[drumstick77]

I think this issue can be closed as far as my concern, it also works on my M8P V1.2 CB1. @Frix-x - Many thanks for your help! much appreciated!