Timer to Close on TH0

[IllSkillz]

Basic Information:

Printer Model: voron
MCU / Printerboard: monster8
Host / SBC: ubuntu vm on truenas server
klippy (51).zip (6.9 MB)

After 28hrs of printing, it threw up timer too close on TH0 (SB2040). It seems that in the log theres no comms issues and the temps are all in check

[EddyMI3D]

Hello @IllSkillz !

You already had a look hera?

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 …

[IllSkillz]

yes and it does make sense when we are talking about host, but with the SB board it doesnt. I had this issues with the mcu so I changed orange pi board to a full fat vm on a server and that solved the issue. With toolhead controller idk

[EddyMI3D]

@IllSkillz

a full fat vm on a server

I hope you will not run into issues later:

Running Klipper in a Virtual Machine (VM)

Running Klipper in a Virtual Machine (VM) Klipper’s Requirements Klipper does not need nor profits from high power CPUs or Giga-Bytes of RAM Klipper requires near-realtime scheduling down to some 100 ms Klipper requires direct and undisturbed hardware access Virtual Machines Offer Scheduling Fairness: Each VM shall have respective resources, access etc Lots of “house-keeping” in the background Abstracted access to USB or other hardware Result It is not secured that Klipper’s requirement…

[IllSkillz]

Ill deal with that issues when the times comes. Im planning to get more powerful orange pi board but currently its out of my budget. Any way its not relevant to the current issue.
p.s. you hope? its not very nice of you

[EddyMI3D]

@IllSkillz

you hope

I wrote this:

@EddyMI3D

I hope you will not run into issues later:

[Sineos]

@IllSkillz

yes and it does make sense when we are talking about host, but with the SB board it doesnt.

The TTC error is a host error and if your host is a VM then the article quoted by @EddyMI3D might very well be applicable.

Unfortunately, the TTC error is one of the least understood errors in Klipper:

• Klipper has a “timing budget” that is strictly enforced to meet the quality requirements
• Every action the host needs to do, e.g. updating something within the Klipper processes OR handling stuff outside of the Klipper processes like webcam or other IO tasks may “eat away” this “timing budget”
• Once the budget is spent, TTC error might occur

This means that a lot of different combinations can finally lead to a TTC error. Of course, there might be single events that are enough to trigger it, e.g. a webcam hogging the USB bus. Also an addition of minor contributors may finally push the budget over the brink.

Edit: An of course unofficial code modifications might be big contributors if the respective coders did not make sure that no combination or usage scenario leads to unexpected host delays.

For example constantly updating LEDs at higher frequencies is a quite sure way to create a TTC.

[IllSkillz]

Im sorry, I cant read today.
Well if my TTC error is related to the host im pretty sure that i know the issue is, its just confusing because in logs its linked to sb board. Is there a way to handle ttc error differently? Shutting down the entire printer feels a bit to harsh specially in the middle of 40hr print. Is there a reason for that? Is it possible to may be just pause the system?
p.s. im running 5m usb cable to the host

[IllSkillz]

btw is timing budget related to the cpu clock/cores? Is there any recommendations for ideal hardware for the host?