Timer too Close on Voron 2.4

General Discussion
1

Basic Information:

Printer Model: Voron 2.4
MCU / Printerboard: Fysetc Spider v1.1 / SB2209 / ERCF Easy Brd (Seeduino XIAO SAMD21) / Raspberry Pi 4 as MCU
klippy.log

Describe your issue:

Hello,

I am getting the “Timer too Close”-Error almost every print now …
However, I wasn’t able to spot anything conspicuous in my log file, the generated log.shutdown-file or in the plots.
Unfortunately, my Klippy-logfile is too big to upload here, so i zipped it:
klippy.zip (1.3 MB)

Can anyone see anything conspicuous in my logfile or can tell me what to do next? :smiley:

Thanks in advance!

Michael

2

Hi,

Although I have a different printer, I’ve also been getting “Timer too close” for almost every print now, it seemed to start yesterday after I updated Klipper and reflashed my firmware. Before yesterday this was a very intermittent fault, and now it is causing every print to fail.

Have you recently updated your host software or reflashed your firmware? (Just trying to identify if there is a commonality in our problems)

3

Yes, i am using the newest version of Klipper (5f990f9).

4

Aside from the standard reasons for such an error listed at Timer too close, you are using a heavily modified version of Klipper:

Git version: 'v0.11.0-271-g5f990f93-dirty'
Untracked files: klippy/extras/autotune_tmc.py, klippy/extras/ercf.py, klippy/extras/ercf_encoder.py, klippy/extras/ercf_servo.py, klippy/extras/manual_extruder_stepper.py, klippy/extras/motor_constants.py
Branch: master
Remote: origin
Tracked URL: https://github.com/Klipper3d/klipper.git

Note that such changes, especially in combination, may cause this behavior. Further support can only be provided if the problem also occurs in an unmodified Klipper.

5

Thank’s for mentioning that, I will clean up the installation if possible. However, those are not modifications but untracked files, so i don’t think, that they are causing any issue.

However, as a short term “solution” I just applied extra cooling to my electronics (except the SB2209), maybe this will help.

Furthermore I noticed, that I am using different versions of Klipper on the MCUs, I’ll update all of them to the newest version next week. Is it possible, that this is causing the issue?

6

“Untracked files” are files that do not belong to the main Klipper repository, or that belong to it but have been modified. This means that their quality is the sole responsibility of the respective developer. Furthermore, combinations of them, i.e. different modifications from different sources, have never been tested for compatibility etc…
As such, they are considered unofficial modifications and bugs are not followed up, since it is completely unclear whether a problem originates from these modifications or from the Klipper core files.

Klipper checks if the versions on the host and on the MCU(s) are compatible. Differences are allowed and if an update is needed Klipper throws an error stating this fact.
Again, unofficial modifications might disrupt this.

7

As far as I know are “Untracked Files” new files, which haven’t been present before and “Modified Files” are Files, which had been present before but they were modified.

However, I got your point and I already removed the autotune_tmc (I didn’t use it anyways). The other modifications were done by the installation of Happy Hare. I googled if this caused errors for anyone else, but I couldn’t find anything.

8

No

Do whatever you want. It is your printer. Topic done from my side

9

Update:

I am still trying to figure out what causes this error. In the meantime I updated all MCUs to the newest version (v0.11.0-271-g5f990f93) and replaced the Raspberry Pi, which had faulty USB ports and was running about 10°C hotter than the new Raspberry Pi. Besides that, I updated the Bootloader of the Raspberry Pi, but I don’t think, that this does matter.

Today I still got this error after about one and a half hours of printing.

Unfortunately, I wasn’t able to find which of my MCUs caused this error. Is it possible to obtain this information from the klippy log file?

Here is the new logfile and the shutdown file:
klippy.zip (1.1 MB)

10

Update:

I just got one finished print, which took about two and a half hours.

The only change I made was to increase the txqueuelen for can0 from 128 (as in CANBUS - Klipper documentation) to 1024.

Hopefully, this did the trick, I’ll start a longer print now and let you know whether it worked or the error persists.

11

I did the same trick on my EBB and it seems to work pretty well with the increased queue length.

12

Update:

And I got “Timer too close” again after about one hour of printing …

Voron Shutdown 30.08. 15-55.zip (3.2 MB)

I just don’t know why …

Is anyone able and willing to help me to gather more information from the log-files?

13

Update:

I reinstalled MainsailOS, I am using another SD-Card and another Raspberry Pi 4. I also switched from OrcaSlicer to PrusaSlicer and again, I got the “Timer too close” error. Taking every failed print into acount it seems like I am getting these errors after about 35 minutes every time.

Finally, I switched from UART to USB for my main MCU, the Fysetc Spider V1.1. The print (sliced the same object but again with OrcaSlicer, 4:40 hours print time) finally finished. :smiley:

Thus, it looks like there is a problem with the UART connection. I don’t know if it was introduced through system updates or Klipper updates. However, this is still a guess and not verified, but I hope the issue is gone forever and won’t appear again …