[BUG] Nozzle temperature not restoring when resuming a print

[GiorgioAresu]

Printer type - MK3S+ Printer firmware version - 3.14.0 (MK3S_MK3S+_FW_3.14.0_MULTILANG.hex)

MMU upgrade - NO MMU upgrade firmware version - N.A.

SD card or USB/Octoprint Octoprint 1.10.2

Describe the bug When clicking Resume print after a pause to insert a few nuts, the nozzle temperature didn't restore to the correct value, it continued showing 0 as target while resuming the next layer. Had to quickly set it back to 210 from the tune menu. What's strange is that when selecting the new temperature, moving the dial clock-wise started already at around that same temperature, like it was already selected. I'm pretty sure it wasn't just a display issue though, because this is the 3rd print of this, and while I was even quicker that the previous 2 prints with the previous firmware (I updated just before printing this), the temperature fell down 10 more degrees, around 175.

To Reproduce

• Start a print with a pause (M601)
• Wait for the printer to stop
• Resume print
• See target nozzle temperature staying at 0

Expected behavior The nozzle temp should have went back to the standard temp

G-code Part Studio 1 (2)_0.2mm_PLA_MK3S_1h47m.txt renamed to txt to workaround the upload extension constraints

Video Just a picture of the octoprint temperature panel. Note that I mistakenly set it back to 215 in the rush before checking the panel

[gudnimg]

What's strange is that when selecting the new temperature, moving the dial clock-wise started already at around that same temperature, like it was already selected.

Just a note, this is a new feature in 3.13.2

Jump to 200°C/50°C in Temperature menu This release brings a new behavior when users manually set the temperature in the LCD Menu -> Settings -> Temperature menu. Previously, both nozzle (hotend) and heatbed temperatures started at 0 °C, and users had to rotate the knob clockwise to increase the temperature incrementally by 1 °C until the target temperature was reached.

However, since most filaments require printing temperatures above 200/50 °C (nozzle/heatbed), we have made an adjustment. Now, starting at 0 °C, a single clockwise rotation will increase the nozzle temperature to 200°C instead of just 1 °C. The same change applies to setting the heatbed temperature (0 °C to 50 °C). This modification allows users to reach their target temperature more quickly.

Similar behavior is applied to the print fan; when turning the knob clockwise from 0, the speed is set to 127, which corresponds to 50% of the RPM range.

If you prefer to revert to the original behavior, simply rotate the knob counterclockwise first, and then you can use it in the same way as before.

[GiorgioAresu]

Nice one. I was on 3.13.2 before the upgrade, but never noticed this nice change, as I never had to use it, this saved me a few more seconds of nozzle cooling. That at least explains that bit.

[gudnimg]

Regarding your problem, when you Resume the print from LCD the printer will send //action:resume and do nothing else. It is up to the host (Octoprint) to then send M602 to the printer before the print job resumes.

The M602 g-code takes care of restoring the temperature which was saved into memory when the print was initially paused with M601. These two g-codes typically go together :)

I recall there is somewhere in the Octoprint UI to specify what g-codes are sent on print resume, but I don't remember where. (it was somewhere under the printer settings)

Hopefully this helps

[GiorgioAresu]

Thanks for explaining. I have no knowledge on this, but is it just that simple? Is it possible that the 2 still interact in some other possibly weird way? Again, this was the third almost identical print (basically same model just changed some dimensions. I didn´t change/update octoprint nor prusaprint, but I didn´t encounter any issue. The only change was the updated printer firmware, from prusa3d_fw_MK3S_MK3S+_3_13_2_7080.hex to MK3S_MK3S+_FW_3.14.0_MULTILANG.hex

[gudnimg]

I found an image in a separate Github issue which shows where the M602 g-code needs to be specified in Octoprint: https://github.com/prusa3d/Prusa-Firmware/issues/3148#issuecomment-1349678117 I hope it helps. I believe this will solve your problem.

---

Hmm I looked back at the code in 3.13.2 and compared to 3.14.0, my understanding is below.

I believe I see why it worked in 3.13.2. Because the firmware would always resume the print as if it was an SD card print (where the firmware needs to have full control), there is no distinction between SD and Host prints when the print is paused. The print is resumed regardless of what the Host (Octoprint) says. But this way the printer incorrectly doesn't ask the Host if it can resume the print job. Instead the printer sends resumed action command to tell the host the print job is resumed now and so Octoprint doesn't allow any customization to the resume g-codes.

In 3.14.0 the firmware is now checking if the saved print job is a SD card print or USB/Host print and treats it differently. This was part of the work to support power panic for host prints. A lot of things were made to be much more consistent under the hood for host printing. Now it is up to the host to control exactly how the print is resumed, the printer firmware does not assume it should restore the same temperature unless told so using M602 (which is specific to Prusa printers).

I think the behavior you see in 3.14.0 is the same in 3.13.2 IF you resumed from the Octoprint UI directly, but as you say the LCD menu behaves differently. In 3.14.0 both resume options should now always behave the same.

I'm not saying what you see isn't an issue... it's open for discussion ofcourse. But hopefully this explains why 3.13.2 and 3.14.0 behave differently when the print is resumed from LCD menu.

[GiorgioAresu]

Makes sense, thanks for looking into it and for the thorough explanation. I added that bit to the octoprint gcode scripts, will test it next time I do a paused print (won´t be soon probably). I'll close this, but maybe it's worth adding a note to the release notes?

[3d-gussner]

@GiorgioAresu Please also install the Active Prusa HostTimer Plugin see https://github.com/prusa3d/Prusa-Firmware/issues/4706

[GiorgioAresu]

Yes thanks, I checked and already have that one