Klipper "timer too close" error on specific model, but Cura works fine ..

[piotrb]

Describe the bug
I really don't have an amazing one .. this may take some back and fourth to get to the bottom of ..

Both Orca 1.5 and 1.6.2. .. and SuperSlicer have this same issue .. (I didn't try Prusa to mix things up) ..

The best I can describe it is that somehow .. after printing the first few mm (this seems to vary between ~2.5 to ~4.5) .. klipper blows up with the following message:

MCU 'toolhead' shutdown: Timer too close
This often indicates the host computer is overloaded. Check
for other processes consuming excessive CPU time, high swap
usage, disk errors, overheating, unstable voltage, or
similar system problems on the host computer.
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

(and yes I'm running a multi mcu setup with a CANbus toolhead .. this shouldn't be a problem and isn't for other models .. )

I started a bit of a monologue on the klipper discord logging my attempts ..
https://discord.com/channels/431557959978450984/550725315278929941/1097022117603717141

all I can guess is somehow the slicer is generating gcode in such a way that its overwhemling klipper and it feels like its not keeping up .. (the error message is quite generic which really doesn't help)

The fun part is that when I slice the same model with Cura .. it works fine ..

3mf File for This Bug
stealthburner_printhead_revo_voron_front.zip
(it wouldn't let me upload the 3mf directly, so I zipped it)

To Reproduce
eh .. print it .. and at least on my printer .. after ~2.5 - 4.5 mm it tends to kill the printer ..

Expected behavior
it should print :)

Screenshots
n/a

Printer model
Voron Switchwire

Desktop (please complete the following information):

• OS: Windows 11
• 1.5.0, 1.6.2 (and also SuperSlicer b8e2779 since I had that sitting around for a test) .. but it does imply the issue is with the shared prusa codebase perhaps

[Misterke]

Is something happening on this one? I'm starting to think OrcaSlicer 1.6.3 is triggering something similar on my Klipperized Sapphire Plus. Too early to state that as a fact though, but I have hit 3x "timer too close" now on a file sliced with OrcaSlicer 1.6.3.

[piotrb]

I managed to find a workaround by slowing down the print .. it definitely seems speed related somehow .. keeping the max speed at no more than 100 seems to do it for me at least ..

[piotrb]

I was relying on MVS to manage the speed for me .. but it seems in some sections where it was bursting past 100 it was too much .. I recently got the issue again when I was tweaking the speed settings and bumped infill to like 125 or 150 .. so I set it back to 100 and its happy again

[Misterke]

But 100mm/s is peanuts and Klipper should not have any problems with that. I'm printing infill at 450mm/s and movements up to 600mm/s on the lowly Robin Nano 1.2 of my Sapphire Plus and except for that one model with OrcaSlicer 1.6.3, that hasn't hit a "timer too close". Looking at the load graphs after printing, I typically see bandwidth and load being way below 50%, but in that failing print at the failure point there was every time a sudden spike of bandwidth above 80%.

As this occurred at least 2 times (the 1st of 3 attempts didn't fail at that point but later on and I don't know whether there the spike was present) at the same point in the file, I'm guessing something in the gcode is causing that spike in bandwidth - possibly some way too detailed movements causing lots of commands over very short period of time.

I would expect that something like that could be detected with some basic gcode analysis before starting the print, no? So, is there any tool that can give an insight into the bandwidth that would be used by a gcode file before actually having printed it and then analyzing the klippy.log? Maybe @SoftFever knows whether something like that exists?

Note that in my case, just reslicing the file with the object positioned slightly differently seems to have avoided the problem or at least reduced the spike to levels where it doesn't fail anymore. I'm unsure why that is though. In the problematic file OrcaSlicer was also complaining that an object was "too close" although it had more than enough clearing. I had ignored that and then hit the problems. In the re-oriented version I let OrcaSlicer layout the object, it moved the one it complained about a couple of mm further away, but since I was NOT printing "per object" and had no brim enabled, I don't see why extra clearance would be needed. Anyhow, that layout after slicing did print correctly and I also could not see a high spike in the bandwidth anymore, but I can still not explain it.

[piotrb]

yea its super weird .. not actually Orca's fault per say .. seems to be something in the PrussaSlicer base .. but yea its super weird .. its specific models .. and like you mentioned other conditions like even the positioning on the plate can make a difference ..

[SoftFever]

@piotrb @Misterke

I suspect the issue is caused by frequent fan speed changes. Orca and SuperSlicer may be adjusting the fan speed frequently for areas that contain many tiny overhangs and bridges. In contrast, Cura does not adjust the fan speed for overhangs, if I recall correctly, so it doesn't have this issue.

Can you confirm if this is the case on your side?

Meanwhile, I'm going to reach out to the Klipper community to inquire if Klipper can handle frequent M106 commands.

[piotrb]

Cura was also substantially slower by default so that may have been a big part of it too .. not sure

[Dustmuffins]

I was having a similar issue with this. It would stop at the same time in the print each time I tried it. Slicing the file with superslicer prevented the issue.

Using an SV06 with Mainsail OS

[SoftFever]

This should be fixed in 1.6.4-beta
https://github.com/SoftFever/OrcaSlicer/releases/tag/v1.6.4-beta

[piotrb]

ooh .. I gotta turn off my speed workarounds and see if I get a shutdown :) Thanks for attempting a fix here :)

[piotrb]

Hmm this still happened to me when I removed switched back to more in line with the default voron profile speeds on 1.6.4-beta3 .. trying again on 1.6.6 to see if that makes a difference ..

Also wondering what this has to do with fans .. I'm printing PLA .. shouldn't that basically be 100% fans all the time anyways?

[piotrb]

No, I'm definitely still getting this with 1.6.6 ..

[ErdbeermarmeladebrotmitHonig]

I think that I am facing the same problem. I'm getting these "Timer too close" errors as well.

As @piotrb, I am running a multi-mcu setup and my toolhead is connected via CAN.

I got this error today, then I changed the CAN speed. Afterwards, I printed the same gcode-file again without re-slicing. During the second print, I got the same error at the same place as during the first print. I attached my gcode file and some photos, which show where the printer stopped.

mmu3-pulley-body-R3_ASA_4h40m.zip

[Dustmuffins]

My next 2 posts may not necessarily be Orcaslicer's fault. I changed my printer from a bedslinger to a CoreXY configuration. Running most gcode seemed fine, but it was hit and miss. Prusaslicer always seemed to work, but reducing my microsteps from 128 to 64 fixed the issue with Orcaslicer.

I started noticing this issue again. Attached the gcode of an affected file. The print stopped somewhere between layer 3 and 5 (still on solid infill). Unfortunately I was in a rush and didn't document the exact place it stopped.

ASA_1h0m_2x X block bearing holder only_0.4noz_.zip

[Dustmuffins]

See my previous post

I had another failure. This time I was able to get pictures of where it failed.
Gcode and .3mf project file:

ASA_2h38m_2x X blocks only_0.4noz_.zip

It looks like it finished layer11 (1.75mm), successfully printed the brim for layer 12, then stopped as before, or as soon as it began printing the inner wall on the first object on layer 12.

[ErdbeermarmeladebrotmitHonig]

Probably, I fixed my issue:

https://klipper.discourse.group/t/timer-too-close-on-voron-2-4/10103/13

[github-actions]

GitHub bot: this issue is stale because it has been open for 90 days with no activity.

[github-actions]

GitHub bot: This issue was closed because it has been inactive for 7 days since being marked as stale.

[piotrb]

Hmm .. so I've been working on a second printer and have not had to deal that much with the original one ..

There is an interesting issue I've ran into and that is on the Mellow SB2040 v2 that I had on the new printer I did NOT run into this issue at all .. on the Mellow SB2040 v1 I have in my switchwire .. I run into this a lot ..

Its also super weird that this is specific to the Prusa slicer derivatives .. I've been forced to use Cura for a bunch of prints because I just can't get them to not cause this problem mid-print ..

I've never ran into this problem on the new printer ..

I actually ordered a V2 board to see if that somehow makes the issue go away on the original printer I'm seeing this with .. if not .. I won't mind having a spare anyways :)

[omarquis]

@piotrb any news? I got the same issue with an Creality Ender V3 KE and a Flashforge 5M. The issue occur more often when I'm using fuzzy skin.