Hotend not turning off after updating to 1.3.7

What is the problem?
After updating to 1.3.7 my hotend no longer shuts off after a print finishes

What did you already try to solve it?
I use S3D and the end codes to shut down the bed and hotend. I always have and it has always worked perfectly. I have done three prints since updating to 1.3.7 and now just the hotend won't shut off after printing. I have searched the forum and the facebook group. I made a post in the facebook group and here.

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
Octo 1.3.7
Wanhao Duplicator i3

The two pictures show the end of the print code from Octo and my S3D settings.

Share a GCODE file please, and a full serial.log.

Dual Aero Mount.gcode (2.5 MB)

octoprint.log (51.1 KB)

That is octoprint.log, I asked for a serial.log (which you'll btw first need to enable, see here) :wink: I need to see what communication happens between OctoPrint and your printer.

1 Like

Oh, and also, please check if the issue persists safe mode.

1 Like

it won't let me post the serial.log file because it is 30mb. What should I do?

Try,, Google Drive, OneDrive, Dropbox, ...

Now why didn't I think of that :wink:

I installed the gcode editor to be sure the code was in the file and it is. Here:
G1 X54.578 Y136.716 F2880
G92 E0
G1 E-2.3000 F2400
; layer end
G28 X0 ; home X-axis
M104 S0 ; turn off extruder
M140 S0 ; turn off bed
M84 ; disable motors

So it looks as though the code was sent but the printer did not turn off the extruder. The bed shut off though.
2018-04-11 23:13:43,268 - Send: N4 M140 S7086
2018-04-11 23:13:43,281 - Recv: ok 4
2018-04-11 23:13:43,285 - Send: N5 M190 S70
2018-04-11 23:13:43,286 - Recv: TargetBed:70
2018-04-11 23:13:43,297 - Recv: ok 5
2018-04-11 23:13:43,301 - Send: N6 M104 S250 T0*32

Looking at the end of the print

2018-04-12 03:05:06,230 - Send: N267514 G28 X0*104
2018-04-12 03:05:06,243 - Recv: T:249.50 /250 B:70.04 /70 B@:0 @:104
2018-04-12 03:05:06,249 - Recv: ok 267513
2018-04-12 03:05:06,252 - Recv: ok 267514
2018-04-12 03:05:06,255 - Send: N267515 M400*21
2018-04-12 03:05:06,258 - Send: N267516 M114*22
2018-04-12 03:05:06,274 - Recv: ok 267515
2018-04-12 03:05:09,131 - Recv: X:0.00 Y:136.72 Z:14.17 E:-2.29
2018-04-12 03:05:09,149 - Recv: ok 267516
2018-04-12 03:05:09,164 - Recv: X:0.00 Y:136.71 Z:14.17 E:-2.29
2018-04-12 03:05:09,198 - Send: N267517 M140 S0*85
2018-04-12 03:05:09,223 - Recv: ok 267517
2018-04-12 03:05:09,231 - Recv: TargetBed:0
2018-04-12 03:05:09,237 - Send: N267518 M84*32
2018-04-12 03:05:09,255 - Recv: ok 267518
2018-04-12 03:05:09,287 - Changing monitoring state from "Printing" to "Operational"

it actually doesn't look like a M104 S0 was sent. So the question is why. What I do see in there is a M400, M114 pair. Stock OctoPrint only sends those when cancelling a print, which was not the case here. Considering how many there are in there, I'm guessing you have Octolapse not only installed but also running here?

I know that this plugin does command replacements, and from the timing of that injected pair which is right where the M104 S0 should be, I'm wondering if what you are seeing here is maybe caused by the plugin. Please disable the plugin or better yet enable safe mode as I mentioned earlier and see if your heater then properly shuts off at the end of a print. If it does, this is an issue in the plugin that will need to be investigated.

@FormerLurker, pinging you since this might be related to Octolapse.

1 Like

I will take a look at this ASAP since it could very well be an Octolapse issue. It looks like Octolapse tried to acquire a position after a home, which is where the M400+M114 comes from right after the G28, but maybe it didn't properly send the next gcode?

@mylomine, can you post your gcode file, or create an issue here? I'll definitely escalate this since we don't want hot ends staying hot after the print!!!!

1 Like

@mylomine, I see the file now, sorry! I didn't read everything before I posted, doah!

So it looks like Octolapse is not properly sending any commands following a home (or any other command configured to reacquire the current position) if the command doesn't have an entry in the parser. This is not good. It looks like I left some remnents of the previous parser in the acquire_position function :frowning: . Once I debug and test I'll push v0.3.2.

1 Like

@mylomine, can you try re-installing Octolapse with this URL:

I don't think you'll need to uninstall first. Rerun the print and let me know if the hotend turns off like it's supposed to now.

1 Like

Ok. I will give it a shot tomorrow. I am sorry I haven't been active today. Work got me :wink: I will report back tomorrow. Thank you both for your help.

The new Octolapse did fix the issue. I reran a print with the new version and the hotend turned off as normal. I did uninstall the previous version just to be safe. I did not run in safemode as I wanted to try with the new version of Octolapse. Thank you both for your help. Sorry it took me so long to report back.

Please mark this as solved then :wink:

1 Like

Thanks @mylomine! I am about ready to push this fix into production. I thought it would be last weekend, but I was experiencing issue armageddon. Let me know if you have any additional problems.

1 Like