CR-10S - Bed starts heating on Octoprint Connection

Hello all,

I have an odd issue I have not seen before. Every time I connect OctoPrint to my CR-10S, it immediately starts heating the bed (to a five-digit temperature!!). I immediately turn the temp off, but it does it each time I re-establish the connection to the printer.

I can't seem to find any information about what is happening, but here is the terminal output on connection:

Connection closed, closing down monitor
Changing monitoring state from "Operational" to "Offline"
Connecting to: /dev/ttyUSB0
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0x6
d7a67f0, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from "Opening serial port" to "Connecting"
Send: N0 M110 N0*125
Recv: start
Send: N0 M110 N0*125
Recv: echo: External Reset
Recv: Marlin 1.1.9
Recv: echo: Last Updated: 2018-07-31 | Author: (none, default config)
Recv: echo:Compiled: Jun 23 2019
Recv: echo: Free Memory: 1011  PlannerBufferBytes: 1232
Recv: echo:V55 stored settings retrieved (655 bytes; crc 38204)
Recv: Unified Bed Leveling System v1.01 inactive.
Recv: Unified Bed Leveling initialized.
Recv: UBL System reset()
Recv: echo:  G21    ; (mm)
Recv: echo:  M149 C ; Units in Celsius
Recv: echo:Filament settings: Disabled
Recv: echo:  M200 D1.75
Recv: echo:  M200 D0
Recv: echo:Steps per unit:
Recv: echo:  M92 X80.00 Y80.00 Z400.00 E415.00
Recv: echo:Maximum feedrates (units/s):
Recv: echo:  M203 X300.00 Y300.00 Z5.00 E25.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo:  M201 X3000 Y3000 Z100 E10000
Recv: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
Recv: echo:  M204 P500.00 R500.00 T1000.00
Recv: echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
Recv: echo:  M205 B20000 S0.00 T0.00 X10.00 Y10.00 Z0.30 E5.00
Recv: echo:Home offset:
Recv: echo:  M206 X0.00 Y0.00 Z0.00
Recv: echo:Unified Bed Leveling:
Recv: echo:  M420 S0 Z10.00
Recv: Unified Bed Leveling System v1.01 inactive.
Recv: Active Mesh Slot: -1
Recv: EEPROM can hold 7 meshes.
Recv: echo:Material heatup parameters:
Recv: echo:  M145 S0 H205 B60 F0
Recv: echo:  M145 S1 H250 B80 F0
Recv: echo:PID settings:
Recv: echo:  M301 P22.20 I1.08 D114.00
Recv: echo:Z-Probe Offset (mm):
Recv: echo:  M851 Z-1.37
Recv: echo:Filament load/unload lengths:
Recv: echo:  M603 L0.00 U100.00
Recv: echo:SD card ok
Recv: ok
Changing monitoring state from "Connecting" to "Operational"
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: FIRMWARE_NAME:Marlin 1.1.9 (Github) SOURCE_CODE_URL: PROTOCOL_VERSION:1.0 MACHINE_TYPE:CR-10S EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:EEPROM:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:Z_PROBE:1
Recv: ok
Send: M20
Recv: Begin file list
Recv: echo:Cannot open subdir MAC
Recv: echo:Cannot open subdir WIN
Recv: End file list
Recv: ok
Send: M155 S2
Recv: ok
Recv:  T:21.25 /0.00 B:27.84 /27409.00 @:0 B@:127
Recv:  T:21.25 /0.00 B:28.18 /27409.00 @:0 B@:127
Send: M140 S0
Recv: ok
Recv:  T:21.25 /0.00 B:28.18 /0.00 @:0 B@:0
Send: M104 S0
Recv: ok
Recv:  T:21.25 /0.00 B:28.47 /0.00 @:0 B@:0
Recv:  T:21.25 /0.00 B:28.64 /0.00 @:0 B@:0
Recv:  T:21.21 /0.00 B:28.64 /0.00 @:0 B@:0

Any suggestions as to how I can fix this would be much appreciated.

Your terminal output doesn't show any kind of temperature set commands other than two commands M140 and M104 right at the end that set a temperature of 0 degrees (which translates to "heaters off"), and that's after the printer is already reporting the ridiculous bed target temperature.

So whatever is happening here, it's happening in your firmware, not OctoPrint.

You can workaround it by putting

M140 S0
M104 S0

into the "
After connection to printer is established
" GCODE Script in your settings, but I strongly recommend to figure out why this happens in the firmware on connect.

Thank you! I also suspect it’s the firmware but the printer doesn’t seem to exhibit any odd behavior when printing from SD card or when disconnected from OctoPrint. It seems the OctoPrint connection is causing this behavior...even if it is the firmware.

I will dig deeper...I am certainly not interested in a gcode workaround.

My money would be on it being the serial connection that causes it. You can try by connecting with something like Pronterface. If that does not cause it, it might be that your firmware misinterprets any of the commands that OctoPrint sends on connect, but that would be highly unusual.

Thanks again, foosel! I will take a closer look when I get home tonight. I connected to the printer via Pronterface without any issue...I had to set the Z offset for my BLTouch which requires temporarily lifting the soft limit on the Z and setting the offset to a modest negative value before turning it back on. I used gcode commands to make those changes.

This seems to have started randomly...I was using OctoPrint without issue...then started strange issues such as not being able to display my web cam for monitoring the print. At that point, I swapped Raspberry Pi hardware and built OctoPrint from scratch - only to reveal this issue.

I have another CR-10S board (factory - not flashed) that I am going to try with this OctoPrint, but I suspect that will work just fine. I do believe there is something up with the firmware - but no idea what. I used the stock Marlin firmware (in this case, this link). The only thing I did differently from these changes was to activate BLTouch using UBL with the proper offsets for my BLTouch mount.

Anyway - first time on these forums and impressed with the very timely assistance so far. Thanks again!

I truly have no idea where else to ask this question - so my apologies for asking here (and open to suggestions as to where else to go)...but assuming the issue I am having could be firmware configuration difference I can see between the stock firmware and my edits is the definition of the motherboard.

The stock has the following config:


The suggested edits (and my current config) has:


Could this be related to my issue?

Well...I have come back to share that I have resolved the issue...and I can't believe it. I took the firmware back to the stock HEX luck. THEN...I swapped out the entire control box with another CR-10S box...and it worked...until I wired everything back up again. So I started removing cables - one at a luck. Each one caused the 5-digit bed temp and for my whole board to go - I stared at it...what did I move over that caused it to stop working. THE INCLUDED MICRO SD CARD! Removed the card and all is well.

Anyway...not OctoPrint related - but a solution none-the-less. Enjoy!

1 Like

Wow. That's something :joy:

1 Like

Thank you! I'm setting up Octoprint for my new CR-10S and was having this same issue. (Very alarming, but I noticed it before anything even got warm, thank goodness!)

Removing the SD card has resolved the issue for me as well.

  • Octopi is a fresh image updated to server 1.3.11
  • Only extra plugin is electr0sheep/OctoPrint-Cr10_leveling
  • CR-10S is fresh out of the box with a couple of successful prints via SD card. Firmware is Marlin 1.1.0
  • I have put scotch tape over the USB cable +5V pin to prevent USB power driving the printer's control board when the power is switched off.

You might also consider the USBControl plugin which could work in your situation rather than the tape.

1 Like

Thanks! USBControl works well. I'm working with the printer firmware at the moment, so it's nice to be able to turn it on and off.
I have a Pi 3B, and I will likely set up a webcam eventually, so the all-or-nothing power could be annoying in the future - but not a fault of the plugin.

I'm a scotch tape user as well :smiley:
Do you know if your plugin also works with a Pi4?
I don't want prints to be ruined because of an error in the middle of the night, that's why I'm asking and not testing my self :wink:

As I mentioned in another thread, my Pi4 is somewhere in transit now. When I receive it, I'll see what sort of USB buses it has and make the plugin compatible with it. It probably has the same split-bus system that the 3B+ has, possibly.

@mbmcavoy The 3B+ has a split bus which might be more usable to you than the 3B. Don't confuse this with an individually-controllable bus. The README for the plugin describes it a little. And also, there are webcams which just use the ribbon cable.

1 Like

Alright. Thank you :slight_smile: