-
-
Notifications
You must be signed in to change notification settings - Fork 833
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Klipper "timer too close" error on specific model, but Cura works fine .. #804
Comments
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. |
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 .. |
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 |
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. |
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 .. |
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. |
Cura was also substantially slower by default so that may have been a big part of it too .. not sure |
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 |
This should be fixed in 1.6.4-beta |
ooh .. I gotta turn off my speed workarounds and see if I get a shutdown :) Thanks for attempting a fix here :) |
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? |
No, I'm definitely still getting this with 1.6.6 .. |
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. |
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.
|
See my previous post
ASA_2h38m_2x X blocks only_0.4noz_.zip
|
Probably, I fixed my issue: https://klipper.discourse.group/t/timer-too-close-on-voron-2-4/10103/13 |
GitHub bot: this issue is stale because it has been open for 90 days with no activity. |
GitHub bot: This issue was closed because it has been inactive for 7 days since being marked as stale. |
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 :) |
@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. |
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:
(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):
The text was updated successfully, but these errors were encountered: