What's new
VORON Design

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members!

Klipper reports: SHUTDOWN MCU 'mcu' shutdown: Timer too close on hard print

Printer Model
voron trident 300
Extruder Type
LGX Lite
Cooling Type
Stealthburner
I just got my voron trident 300 used. Few great prints. Doing a very challenging one and twide have gotten
Klipper reports: SHUTDOWN

MCU 'mcu' shutdown: Timer too close

I slowed the speed factor down to 70% after the last one happened only an hour or so. This one was about 15hrs in.

I've attached the logs and config. New to klipper and voron but have been printing for years.

Klippy log is giving me issues attaching even zipped. had to max compress it.

Stats 74831.9: gcodein=0 mcu: mcu_awake=0.015 mcu_task_avg=0.000012 mcu_task_stddev=0.000010 bytes_write=314361711 bytes_read=56363033 bytes_retransmit=9 bytes_invalid=0 send_seq=5692370 receive_seq=5692370 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=39 upcoming_bytes=2750 freq=180001250 sd_pos=131558573 heater_bed: target=60 temp=60.1 pwm=0.045 raspberry_pi: temp=64.5 mcu_temp: temp=34.4 sysload=3.08 cputime=9808.340 memavail=682676 print_time=74836.564 buffer_time=2.284 print_stall=0 extruder: target=205 temp=204.8 pwm=0.478
Stats 74835.0: gcodein=0 mcu: mcu_awake=0.010 mcu_task_avg=0.000011 mcu_task_stddev=0.000010 bytes_write=314371657 bytes_read=56366570 bytes_retransmit=743 bytes_invalid=0 send_seq=5692541 receive_seq=5692541 retransmit_seq=5692503 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=180001239 sd_pos=131563503 heater_bed: target=60 temp=60.2 pwm=0.014 raspberry_pi: temp=63.9 mcu_temp: temp=34.3 sysload=3.56 cputime=9808.557 memavail=678732 print_time=74837.433 buffer_time=0.115 print_stall=0 extruder: target=205 temp=204.9 pwm=0.468
MCU 'mcu' shutdown: Timer too close
clocksync state: mcu_freq=180000000 last_clock=13470717198556 clock_est=(74804.876 13465302799379 180001239.875) min_half_rtt=0.000116 min_rtt_time=74162.562 time_avg=74804.876(852.907) clock_avg=13465302799379.564(153524377925.910) pred_variance=56788494.682
Dumping serial stats: bytes_write=314371657 bytes_read=56366570 bytes_retransmit=743 bytes_invalid=0 send_seq=5692541 receive_seq=5692541 retransmit_seq=5692503 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0
Dumping send queue 100 messages
Sent 0 74832.942223 74832.942223 58: seq: 19, queue_step oid=12 interval=35643 count=18 add=-204, queue_step oid=9 interval=30836 count=12 add=257, queue_step oid=18 interval=551921 count=1 add=0, queue_step oid=9 interval=36729 count=6 add=2783, queue_step oid=12 interval=30313 count=12 add=-196, queue_step oid=9 interval=57916 count=6 add=0, queue_step oid=18 interval=432860 count=1 add=0
 

Attachments

  • moonraker-2-28.log
    11.6 KB · Views: 3
  • config-20240228-063619.zip
    4.7 KB · Views: 3
  • klippy-2-28.zip
    939.8 KB · Views: 2
Last edited:
Starting the remaining portion of the print. Getting some of these in Syslog. The syslog and daemon file was huge before i did a rotate on it.
Feb 28 21:57:50 trident klipper_mcu[395]: Got error -1 in write: (11)Resource temporarily unavailable
Feb 28 21:57:55 trident klipper_mcu[395]: Got error -1 in write: (11)Resource temporarily unavailable
 
Thanks since the "Resource temporarily unavailable" may have began with me hitting the "update" buttons on my machine that would likely coincide with the timing of these new messages. I'm also waiting to see if the print succeeds or fails again. I have resliced the parts from the fail point. I have a couple more big prints with lots of details coming up. I should be able to implement some of the stuff on this at end (or fail) of print tonight and get back with folks.

I will be searching around for ways to optimize so I don't have to slow it down for this AND for better first few layers especially small supports. I won't rule out this print just being nuts on the level of detail direction changes and acceleration and decelerations...
 
was already masked...
pi@trident:~ $ systemctl status ModemManager.service
● ModemManager.service
Loaded: masked (Reason: Unit ModemManager.service is masked.)
Active: inactive (dead)
pi@trident:~ $

I also tipped it and checked the usp cord route. It might be the cord that comes with the octopus board, it was doubled back in with a couple other wires. Reseated it and disconnected the web cam for this print.

The Resource temporarily unavailable errors went away.
 
Also found this

udev: Installed: 247.3-7+deb11u2 Candidate: 247.3-7+deb11u2 Version table: *** 247.3-7+deb11u2 500 500 http://deb.debian.org/debian bullseye/main arm64 Packages 100 /var/lib/dpkg/status
 
Top