Timer too close - so far, two prints failing on the same layer, WTF?

Basic Information:

Printer Model: Voron 2.4r2
MCU / Printerboard: Octopus
Host / SBC: Raspberry Pi 4
klippy.log - 2 failing logs attached, with respective gcode inputs.

Describe your issue:

I started getting the TTC error tonight and it seems to be consistently failing on the same layer even with a modified gcode file. The first attempt was several pieces, four of which finished so I removed them from the plate and broke the rest of the stuff up a little more. When I tried to print the “handle” and “guide” again, klipper got to the exact same layer and failed again in nearly the same spot (see blue circle below).

I’ve looked through the klippy.log files and I can’t make heads nor tails of it. The first time it seemed like it might be related to neopixel stuff on the sb2209 so I removed all the SB logo calls from my neopixel commands but that didn’t seem to resolve the problem. What’s the best way to troubleshoot this instead of trial and erroring it to death?

2 klippy failing logs.zip (1.9 MB)

2 Failed Gcodes.zip (3.0 MB)

I looked through the klippy.log files for the name of the gcode file but it isn’t found, seems like that should be recorded somewhere in the log file… I tried running the graphs recommended in the knowledge base article on TTC but those seem to be fine when the MCU seems to die. :man_shrugging:

If we knew the philosopher’s stone to solve this error, we would certainly have already published it here.
Unfortunately, all that remains is to narrow down the error step by step.

I also started to get TTC erros after the last update. downgrading solved the issue.

My guess it has something to do with removed configuration stuff, but didn’t have the chance to debug the issue thoroughly.

1 Like

Hello @thisisit

On the same gcode files as the OP?

I’ve also had an MCU timing issue with this particular recent commit;

1 Like

If you are on the most current git and experience this issue, you could try checking out the committ just before this change series, e.g.:

sudo service klipper stop
cd ~/klipper
git checkout 293858c51fc51c998a046ba12c00da0418fb8403
sudo service klipper start
3 Likes

The above works for me, I assume it affects fan.py, servo.py as they both call the new queue_gcode_request from output_pin.py.

No, but thought I’d share my problem, which is similar to op’s, and how I temporarily worked around it.

I’ve seen a few reports of problems recently. However, to date, all logs I’ve seen from the event were with modified versions of Klipper. If someone can reproduce the issue on pristine Klipper (no code modifications, no external code added) then I’ll take a look. Make sure you are on the latest version of the code (there was some changes a few hours ago to the queuing logic - commit cc4ad667), reproduce the issue, and then attach the full unmodified log here on Klipper Discourse.

-Kevin

I just printed my 2nd attempt again, backing out this change like Sineos suggested and the print completed without issues! I’m going to keep printing and I’ll respond if I see anymore TTC errors.

1 Like

From reports and experiences here, two modifications that definitively promote TTC errors are:

  • LED effects
  • MMU / Happy Hare

I can confirm the issue with timer when upgrading to latest version. I updated all my mcu’s firmware in the hopes it would solve the problem, but still no joy. It would error out during homing. Attached is the original klipper.log and the updated one. Downgrading seems to have solved the issue.
klippy2.log (316.0 KB)
klippy.log (242.5 KB)

i have to preheat my hotend to avoid this error before launching any print

A recent commit did introduce an error (with heater_fan, temperature_fan, and/or controller_fan modules). I’ve reverted the recent fan queuing changes until this can be resolved (commit 900bf2be).

-Kevin

Thanks Kevin, does this mean I can go back to mainline git branch?

I’ve been printing constantly since rolling back that last commit and haven’t experienced another TTC (5 successful prints thus far).

1 Like

Yes, Kevin reverted the problematic commit. If you followed above approach, you can go back to current git main line with:

sudo service klipper stop
cd ~/klipper
git checkout master
git pull 
sudo service klipper start
1 Like

To go back to master, would I just “git checkout master”?
How does one know the git branch for previous version if everything is under master?

Found out how using git-log to look at latest commits.

SOVOL SV08 copy errors; BUT WORSE; just some here

BAD Design in this part:-

Even had to stop the doors rattle

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.