Klipper Expander MCU Shutdown: Timer too close

General Discussion
1

Basic Information:

Printer Model: Voron v0.2r1
MCU / Printerboard: SKR Pico
Host / SBC: BTT Pi V1.2
klippy.log
klippy.log (1.1 MB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

Hello,
I am getting the “MCU Shutdown: Timer too close” error on a recently built Voron v0.2. This error only occurs before the print actually starts, and I believe it only happens after homing, but I am not 100% sure on that.

I looked perused the forums here but couldn’t find any obvious solutions, so hopefully the attached log has some clues. Any insight would be greatly appreciated.

2

Please look through these post before adding anymore to this post, thanks.

https://klipper.discourse.group/search?context=topic&context_id=16873&q=Timer%20too%20close&skip_context=true

2 Likes
3

Thanks for the list. I can cross off some things from this list right away, but am unsure of where to go from there.

This error only occurs somewhere in the “start print” section of gcode, it has never happened during a print. Given that, I think I can rule out the following:

  • Disk error / Dying SD card (I’d expect this behavior to be more erratic than what I am experiencing)
  • Wiring Faults / EMI (same reason as above)
  • Running a virtual machine (not running one)

I doubt it I have an unstable voltage, but I am also not sure how to check that. Any advice there would be useful.

That basically leaves me with a software/config issue, as far as I can tell.

I did manage to get graphs and a log of the issue occuring again today. This happened after I canceled a print, in case that information is relevant.

logs-20240606-211424.zip (137.1 KB)

loadgraph_mcu
loadgraph_mcu800×600 53.5 KB

loadgraph_mcu
loadgraph_mcu800×600 22.9 KB

loadgraph_freq
loadgraph_freq800×600 35.7 KB

The frequency graph looks a bit erratic, but I can’t find any information about how to decipher it.

4

Cross off the rest of the items and be really sure to have them crossed properly.
There is, on Klipper’s side, no issue known that might be causing this effect and also no configuration option.

What I should amend to this list:
There are certain slicer versions and or (wrongly coded) macros floating around that will flood Klipper’s queue with meaningless commands, e.g. fan speed changes 100 times a second, that can also lead to this error.

1 Like
5

There is, on Klipper’s side, no issue known that might be causing this effect and also no configuration option.

Right, I meant that likely leaves me with an issue with my software/config, not necessarily with Klipper itself.

I haven’t seen any gcode commands being flooded in the file, but I did find that a particular gcode file has thrown the error every time so far.
LargeOverhangTest-110mm_ABS.gcode (1.4 MB)

It is still strange to me that even with other files, the error only occurs before the actual print starts. For reference, this is my start gcode:

_WAIT_INDICATOR
SHOW_BUILD_SHEET
M104 S160 ; immediately start preheating extruder
M140 S[first_layer_bed_temperature] ; immediately start heating bed

M109 S160 ; wait to reach extruder setpoint of 160
M190 S[first_layer_bed_temperature] ; wait to reach bed temp

_PRETTY_INDICATOR
G4 P1200000 ; let bed and chamber heatsoak for 20 minutes

print_start ; run print start macro

G90 ; Ensure printer is set to absolute positioning

G0 X119.5 Y-1 ; Go past bed limit before heating so ooze falls to bottom
G0 Z5 ; Drop to bed

M109 S[first_layer_temperature] ; heat extruder to first layer temp
_NOZZLE_PURGE ; run purge line macro

SKEW_PROFILE LOAD=calilantern_skew_profile

I wonder if the large dwell time I have has something to do with it, since the error has only occured after G4 P1200000 and before SKEW_PROFILE LOAD=calilantern_skew_profile.

My print_start macro looks like this:

[gcode_macro PRINT_START]
#   Use PRINT_START for the slicer starting script - please customize for your slicer of choice
gcode:
    M400                           ; wait for buffer to clear
    SET_GCODE_OFFSET Z=0.0
    CLEAR_PAUSE
    SAVE_GCODE_STATE NAME=PREPRINT_STATE
    _RUNNING_INDICATOR              ; display "running" status on led
    M400                           ; wait for buffer to clear
    G28                            ; home all axes
    G90                            ; absolute positioning    
    G1 Z20 F3000                   ; move nozzle away from bed
    APPLY_BUILD_SHEET_ADJUSTMENT
    SET_FILAMENT_SENSOR SENSOR=sfs_switch_sensor ENABLE=1     ; enable filament runout detection
    #SET_FILAMENT_SENSOR SENSOR=sfs_encoder_sensor ENABLE=1   ; motion sensor disabled, not connected
    G92 E0 ; zero extruder, in case previous print was cancelled
    STEPPER_COOLING_ENABLE

…and the nozzle_purge macro:

[gcode_macro _NOZZLE_PURGE]
description: Draw a purge line at the front left edge of the build plate
gcode:
    M400                           ; wait for buffer to clear
    G90 ; Ensure printer is set to absolute positioning
    ;G0 X120 Y-2.5 ; Go past bed limit to hopefully drag any ooze off build plate - done in slicer
    ;G0 Z0.15 ; Drop to bed - done in slicer
    G0 X117 Y-1 F3000 ; Go to front left
    G0 Z0.15 ; Drop to bed
    G92 E0 ; Reset E position; just in case
    M82 ; Set extruder to absolute mode
    G1 Y39.5 E18 F500 ; Extrude 16mm of filament in a 4cm line
    G1 E17.75 F800 ; Retract a little
    G1 Y44.5 F4000 ; Quickly wipe away from the filament line
    G1 Z0.3 ; Raise and begin printing.
    G92 E0 ; Reset E position to 0

So my assumption was that something within that part of the code and/or the associated macros is causing it to trip

6

Update to the issue:
I split the original 20 minute G4 dwell command into 1 minute segments with an M400 in between, like this:

[gcode_macro DELAY_20]
Description: Twenty minute dwell split into one minute increments
gcode:
  # First 5 min block
  G4 P60000 ; let bed heatsoak for 1 minute
  M400
  G4 P60000 ; let bed heatsoak for 1 minute
  M400
  G4 P60000 ; let bed heatsoak for 1 minute
  M400
  G4 P60000 ; let bed heatsoak for 1 minute
  M400
  G4 P60000 ; let bed heatsoak for 1 minute
  M400
(...etc...)

I am not sure if the M400 command is needed, but I haven’t gotten a “Timer too close” error since doing this, so it appears to have resolved the issue.

I’m guessing that this has something to do with a buffer getting full and the microcontroller not being able to respond until the dwell command finishes.

Either way, appreciate everyone’s help.

7

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