MCU 'mcu' shutdown: Timer too close when homing

[JuanR3D]

Basic Information:

Printer Model: Custom
MCU / Printerboard: Manta M8P
Host / SBC CB1
klippy.log
klippy.log (6.1 MB)

Describe your issue:

Hi. My printer just gets this error when performing g28 command and i dont understand why.

I have edited some .py files in order to fix a problem i have with horizon. Basically the idea is to set a dwell (G4) previous to homing z, and also, before performing the second home.

In order to do that, i have modified safe_z_home, adding a g4 previous to home z, and in homing.py, i have also added a g4 preivious to the second home, but i guess this is no the problem (i hope)

I atach them:
homing.zip (4.9 KB)

[nefelim4ag]

Timer too close

Background A “Timer too close” error occurs when the MCU attempts to schedule a timer for a target time that is in the past. It almost always occurs as a result of a message from the host requesting an action at a time that is now in the past. It is important to understand that Klipper essentially knows which command was scheduled in the past, but not why it happened. For example, a message is delayed because the webcam is blocking the USB port: The message contains a command whose target time …

Latency/bandwidth issue.

Also, there are system load:

also, there are mysterious temperature_logger.py

BTW, this is not a good idea to modify files and add random code commands.

[JuanR3D]

I will try to make the printer fail in that way and run the graphstats command in order to generate those graphs, maybe we can see something inusual.

Temperature_logger.py is not the problem as i have experienced this issue even not having It loaded in klippy extras, also, I wasn’t executing it in that moment.

In a first moment, i was very sure that the problem was a very big sample count value i had set in order to make the machine count a lot of samples before setting the endstop as triggered, but i guess this was making the mcu stay in a waiting mode, attending to this event, so other commands were being queued in the past. But after reverting these changes, i still have this problem, so i Guess i have some other process running in the machine causing this problem.

[JuanR3D]

Hi again @nefelim4ag .

I solved this problem reverting my changes on homing.py and updating klipper and everything (i dunno wich of these changes was the one to fix the problem but at least now it is working)

Neverthless, i want to check my mcus ussage by running the graphstats commands, but I get this error:

~/klipper/scripts/graphstats.py /tmp/klippy.log -o loadgraph_mcu.png -s
/usr/bin/env: ‘python’: No such file or directory

[Sineos]

These script have as shebang:

#!/usr/bin/env python

Depending on the Python version you use and the packages you have installed the “pure” python command might not be available.
Call the script via:

python3 ~/klipper/scripts/graphstats.py /tmp/klippy.log -o loadgraph_mcu.png -s

[JuanR3D]

Thanks @Sineos ! Now the script is executing, but there is another error:
FileNotFoundError: [Errno 2] No such file or directory: ‘/tmp/klippy.log’

Fixed it just setting the correct directory, in my case:
/home/biqu/printer_data/logs/