Klipper is shutting down while heating

General Discussion
1

Basic Information:

Printer Model: Tronxy X5SA pro
MCU / Printerboard:
klippy.log
klippy (3).log (1.1 MB)

Describe your issue:

Klipper is shutting down while heating the bed
I wanted to do a bedmash, thats why I preheated the bed to 60° . But before it reaches this temperature Klipper is shutdown without any further information. The last time I used this printer everything was working fine and nothing was changed since then. Maybe someone can see the issue in the klipper log :slight_smile:
Thanks in advance

2

When I start a PID tuning with target bed=60°C it is not shutting down. The temperature itself should not be the problem…

3

Hello @ajdan !

It seems, the bed is not able to reach the 60°C.

grafik

grafik

4

Thanks for your reply, but do you know what can be the reason? Because when I do the PID tuning command it reaches the 60°C without any problems :confused:

5

If the bed does not reach the desired temperature, either printer is in a place that is too cool/cold or a weak power supply.

6

But why can it reach the temperature while it’s PID tuning and seconds later it’s not able to heat up to 60 degrees.

I’ll check the wiring tomorrow, maybe something is loose.

After updating klipper it now says it lost communication to the mcu when it’s shutting down… :thinking:

7

When the bed heating aborts, is the hotend also heating?

8

No, just the bed is heating…

9

When you set to 65°C does it exceed the 60°C mark?

10

I don’t have an answer, but wondering how long does it take before it shutsdown (is it an idle timeout) and if you try to heat the bed to 50 does it work?

While the bed is heating does the rest of the printer work? Meaning can you move any axes, turn lights on and off, etc?

11

@ajdan
I would recoomend a new PID run

12

The OP is just heating: You can read the times in the klippy.log

13

No, not an idle timeout. Directly after the PID tuning the bed is still hot and I start to set it to 60° it’s working until I set any other command.
When I start the printer new and I set it to 60° it’s not able to reach the 60…
I have no idea what to do

14

I did it three times today. No luck…

But I’ll try tomorrow to set 65° and see what happens :slight_smile:

1 Like
15

I assume you stored the PID results with SAVE_CONFIG.

16

It does look like the mcu stops talking. Would a klippy.log file with debug messages enabled help explain why?

Stats 1562.2: gcodein=0 mcu: mcu_awake=0.001 mcu_task_avg=0.000013 mcu_task_stddev=0.000010 bytes_write=2449 bytes_read=14044 bytes_retransmit=0 bytes_invalid=0 send_seq=254 receive_seq=254 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=72003630 heater_bed: target=60 temp=58.4 pwm=0.731 sysload=0.09 cputime=19.665 memavail=3448768 print_time=7.627 buffer_time=0.000 print_stall=0 extruder: target=0 temp=28.1 pwm=0.000
Stats 1563.2: gcodein=0 mcu: mcu_awake=0.001 mcu_task_avg=0.000013 mcu_task_stddev=0.000010 bytes_write=2455 bytes_read=14089 bytes_retransmit=28 bytes_invalid=0 send_seq=255 receive_seq=254 retransmit_seq=255 srtt=0.003 rttvar=0.000 rto=0.400 ready_bytes=0 stalled_bytes=0 freq=72003630 heater_bed: target=60 temp=58.4 pwm=0.731 sysload=0.08 cputime=19.678 memavail=3448880 print_time=7.627 buffer_time=0.000 print_stall=0 extruder: target=0 temp=28.1 pwm=0.000
Stats 1564.2: gcodein=0 mcu: mcu_awake=0.001 mcu_task_avg=0.000013 mcu_task_stddev=0.000010 bytes_write=2461 bytes_read=14089 bytes_retransmit=35 bytes_invalid=0 send_seq=256 receive_seq=254 retransmit_seq=255 srtt=0.003 rttvar=0.000 rto=0.800 ready_bytes=0 stalled_bytes=0 freq=72003630 heater_bed: target=60 temp=58.4 pwm=0.731 sysload=0.08 cputime=19.690 memavail=3448548 print_time=7.627 buffer_time=0.000 print_stall=0 extruder: target=0 temp=28.1 pwm=0.000
Stats 1565.2: gcodein=0 mcu: mcu_awake=0.001 mcu_task_avg=0.000013 mcu_task_stddev=0.000010 bytes_write=2467 bytes_read=14089 bytes_retransmit=48 bytes_invalid=0 send_seq=257 receive_seq=254 retransmit_seq=256 srtt=0.003 rttvar=0.000 rto=1.600 ready_bytes=0 stalled_bytes=0 freq=72003630 heater_bed: target=60 temp=58.4 pwm=0.731 sysload=0.08 cputime=19.702 memavail=3448552 print_time=7.627 buffer_time=0.000 print_stall=0 extruder: target=0 temp=28.1 pwm=0.000
Stats 1566.2: gcodein=0 mcu: mcu_awake=0.001 mcu_task_avg=0.000013 mcu_task_stddev=0.000010 bytes_write=2473 bytes_read=14089 bytes_retransmit=73 bytes_invalid=0 send_seq=258 receive_seq=254 retransmit_seq=258 srtt=0.003 rttvar=0.000 rto=3.200 ready_bytes=0 stalled_bytes=0 freq=72003630 heater_bed: target=60 temp=58.4 pwm=0.731 sysload=0.08 cputime=19.712 memavail=3448520 print_time=7.627 buffer_time=0.000 print_stall=0 extruder: target=0 temp=28.1 pwm=0.000
Timeout with MCU ‘mcu’ (eventtime=1567.237669)
Transition to shutdown state: Lost communication with MCU ‘mcu’

17

Yes :slight_smile: After the first time today I was not sure if I did the save_config, so I did it another two times and saved it

18

Just came to my mind that I use a different USB cable than the last times!

It is longer and therefore I can hide it better behind the printer (the Raspberry Pi is under my other printer, so I thought the longer cable would be better)

I’ll try again tomorrow with my old USB cable. Maybe it’s just the cable.
That would be nice!

1 Like
19

It’s not the usb cable…

But it’s working when my USB Webcams are not plugged in…

20

What I can see in the logs is, that your heater overshoots a bit due to the long heating time (The I-Part of the PID is maybe not limited in the implementation). So let’s assume, you got a problem with the power supply of the TronXY Board or with overheating of some ICs.

If you decrase the
[heater_bed]
max_power: 1.0

to let’s say 75% (=0.75) does this change something? Is the bottom of your heatbed insulated (i strongly recommend this! This will speed up the heating a lot!)? Did you switch off all fans? Could you place something on your heatbed during heat-up-test to insulate it a little?

Using 100% of the available power, this always leads to problems, especially if the periode you use “full power” for a longer time as expected (i know: noone expects the spanish inquisition!)

Why does it work for PID tuning: Maybe they use different I-Settings during the test? This would explain the behaviour.