Reaching target hotend temp freezes print and triggers communication timeout

What is the problem?

Cant start a print with octoprint even though i can print from printer sd card with no issues. i can control the printer in octoprint web ui though.

so when i load and print gcode, the bed will reach target temp no problem, but when the hotend tries to reach target temp, the print freezes and i get a communication timeout in the terminal. also i noticed when reaching target hotend temp, it defaults to 170degrees. very Odd.

also my printer is constantly trying to do a filament change but i have not seen any m600 command in the gcode.

pls help. thanks.

What did you already try to solve it?

i reflashed and used other sd cards to rule out bad sd card. i also replaced usb cable with a new cable that has ferrite chokes on both ends.

Have you tried running in safe mode?


Did running in safe mode solve the problem?

no success either

Complete Logs

octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support! Not log excerpts, complete logs.)

[serial (2).log|attachment](upload://qQXeUGH3RgbgjeHpkOvpElBZszH.log) (33.0 KB) [octoprint.log|attachment](upload://dbTXwEyTVU1eQEzhP054uAQBrxQ.log) (101.4 KB) 

Additional information about your setup

OctoPrint version 1.5.2, OctoPi version 0.18.0, printer= artillery sidewinder x1, firmware= marlin 2.0.7 (self compiled but not sure if perfect/ prints from printer's sd card with no issues), browser= chrome, operating system= windows 10,


Hello @xsnipex101 !

One request: Either attach your logs as file or please use the </> in the editors menu bar for logs etc. (You may have to enable the serial.log before.)
Things get lost.
Like here:

I'm missing the line where the hotend is set to 170°C

1 Like

my apologies..i just enabled serial log. so it isnt attached here.

octoprint.log (101.4 KB)

this is the cura sliced gcode in case u need it . thank you.

ASX1_xyzCalibration_cube.gcode (375.8 KB)

here you go, attempted failed print with serial log attached.
serial (2).log (33.0 KB)

This is really strange:

Here the print begins with setting the bed to 70°C according to the gcode file:

M140 S70
M190 S70

This is ok.

2021-03-22 14:47:28,221 - Changing monitoring state from "Starting" to "Printing"
2021-03-22 14:47:28,235 - Send: N1 M140 S70*83
2021-03-22 14:47:28,239 - Recv: ok
2021-03-22 14:47:28,242 - Send: N2 M105*37
2021-03-22 14:47:28,249 - Recv: ok T:20.31 /0.00 B:20.47 /70.00 @:0 B@:127
2021-03-22 14:47:28,252 - Send: N3 M190 S70*92
2021-03-22 14:47:28,258 - Recv:  T:20.31 /0.00 B:20.47 /70.00 @:0 B@:127 W:?
2021-03-22 14:47:28,944 - Recv:  T:20.31 /0.00 B:20.47 /70.00 @:0 B@:127

And here:

2021-03-22 14:48:59,292 - Recv:  T:20.31 /0.00 B:71.94 /70.00 @:0 B@:71 W:1
2021-03-22 14:49:00,260 - Recv: echo:busy: processing
2021-03-22 14:49:00,292 - Recv:  T:20.47 /0.00 B:72.18 /70.00 @:0 B@:67 W:0
2021-03-22 14:49:00,524 - Recv: ok
2021-03-22 14:49:00,527 - Send: N4 M113 S2*101
2021-03-22 14:49:01,044 - Recv:  T:20.62 /170.00 B:72.34 /70.00 @:127 B@:49
2021-03-22 14:49:03,044 - Recv:  T:20.94 /170.00 B:72.66 /70.00 @:127 B@:58

then, when the bed reaches temperature, out of nowhere, the extruder is set to 170°C.

I that stock firmware on the printer?

not stock firmware..i upgraded to btt skr board and compiled marlin 2.0.7 to accomodate my mods like bltouch, btt tft35, sensorless homing, uart.

printer works like a charm when printing from sd card. but unsuccessful when printing with octoprint.

im not sure if i compiled the firmware right because i cant get the filament runout sensor to work and filament change feature to work. but when i compiled marlin in vscode, it was a sucsess..

@Ewald_Ikemann, @xsnipex101,
Even stranger is the fact that the .gcode file contains (comments added by me):

M140 S70 ; 1
M105 ; 2
M190 S70 ; 3
M104 S210 ; 4
M105 ; 5
M109 S210 ; 6

and the serial.log contains:

2021-03-22 14:49:00,524 - Recv: ok
2021-03-22 14:49:00,527 - Send: N4 M113 S2*101
2021-03-22 14:49:01,044 - Recv:  T:20.62 /170.00 B:72.34 /70.00 @:127 B@:49

Where the heck did the M113 come from?

Afaik, OctoPrint inserts it for long running commands:

After reading that issue it explains the M113 but it looks to me like we need to know what the Settings, Serial Connection, Intervals & timeouts page looks like.

Also, when I send an M113 S2 to my LulzBot TAZ 6 it responds with ok:

Send: M113 S2
Recv: ok P15 B4

So I'm still confused by the contents of the serial.log.

1 Like

Me too. Where does that 170°C for the hotend come from? That make the printer unsafe.

I think we need @xsnipex101 to enter some commands manually in the OctoPrint terminal window. I'd start with:

M113 S2

Should get two temperature reports surrounding the ok from the M113 command.

I'm going to take a guess, could be completely out but if there is a filament sensor active, then this would make sense:

  • Start print
  • Filament is out, so heat the hotend for a filament change
  • Waiting for user to press button on LCD creates a timeout

Usually, Marlin should have busy protocol enabled and should not timeout. However, I have seen a number of bugs reported (to OctoPrint) that the release (and probably others) have issues with timeouts on filament change. Reportedly using the latest bugfix branch has these issues fixed.

Again, a bit of a shot in the dark but it is the feeling I am getting. Based as well on the mention of the filament sensor somewhere.


Exactly what is happening. I will try getting tbe bugfix. Thanks


i had a rash of communication errors that usually happened a few minutes after print started - cure for mine was replacing the USB cable between PI and Printer with one that was shielded better.

About this...
Have you tried to leave the printer in the 'preheat'-menu?
If I don't, after a while - like you describe - I loose connection to the printer while printing from for example Octoprint (also other programs).
But I leave it in that submenu it works just fine.

I have had this problem with multible sidewinders by the way and it seems to be in combination with the original touchscreen on the printer.
When I disconnect the touchscreen, the problem is also solved.

Well, not a problem anymore since I leave the printer in it's submenu for the preheat after starting that and I can print for days without any issue.
I remember that this issue was listed in the problem-list at artillery when I was still active in those groups to do problem-solving.