Extruder and Bed heating swiched off once the SD card print is on going

[NightSkySK]

Recently, I've started to print more from SD card, rather than from Octoprint and I found some issues which I believe might be triggered by the HeaterTimeout plugin. Reproduction scenario: Prusa MK3S + MMU2S Octoprint at Raspberry Pi3B+ connected via dedicated pin header on Prusa Einsy board OctoPrint 1.4.0 running on OctoPi 0.17.0 HeaterTimeout (0.0.1) settings: Polling Interval 15s Heater Timeout 600s

1. During preparation for print, I set preheat on Prusa directly to heat up extruder for cleaning it usually takes a few minutes.
2. After my extruder is cleaned I've select print from SD card on my printer directly.
3. The printer starts all sequence to load filament, adjust heat table and extruder to a given temperature
4. printer do table leveling and start printing
5. After a few minutes (which I believe is about 10 min starting from preheating) printer switch off heating of extruder and bed.

My assumption is that HeaterTimeout didn't detect that SD card print have been started in the meantime and triggered switch of heating

[precision]

Your assumption does sound quite likely. That is one of the use cases I wrote the plugin for, starting heating via LCD, but then left and forgot to cool it down.

I don't think there is anyway for the plugin to know you're printing via SDcard, but I'll check.

If not I don't really a work around for you aside from disabling the plugin or disconnecting OctoPrint before you start.

[NightSkySK]

Actually the Octoprint is detecting that Printer is busy with printing file from SD even if that was triggered on Printer LCD:

So far I've disabled the plugin, but I thought that it may be something which could be considered to further improve

[precision]

Hrm, I wonder if that isn't plumbed through to the API call _printer.is_printing().

Can you try adding the following to ~/.octoprint/logging.yaml?

loggers:
  octoprint.plugins.HeaterTimeout:
    level: DEBUG

And then try printing from the SDCard and grabbing the output of ~/.octoprint/logs/octoprint.log

[NightSkySK]

I will try to duplicate it with the extended logging. Is it possible that ~/.octoprint/logging.yaml hasn't existed in my case and need to create it, or I've made something wrong? So far I can share the terminal logs how the Octoprint switches the stages once SD card prints start:

Recv:  E/D=Auto
Recv: covid19_rc32_4pcs_complete_0.25mm_PET_MK3SMMU2S_5h33
Recv: SD printing byte 2693/19015124
Changing monitoring state from "Operational" to "Starting print from SD"
Recv: 00:03
Recv: ok
Send: M105
Recv: ok T:266.7 /265.0 B:84.9 /85.0 T0:266.7 /265.0 @:27 B@:62 P:44.2 A:40.3
Send: M27
Recv: covid19_rc32_4pcs_complete_0.25mm_PET_MK3SMMU2S_5h33
Recv: SD printing byte 3215/19015124
Recv: 00:03
Recv: ok
Changing monitoring state from "Starting print from SD" to "Printing from SD"
Send: M105
Recv: ok T:267.2 /265.0 B:85.0 /85.0 T0:267.2 /265.0 @:21 B@:59 P:44.3 A:40.2
Send: M27
Recv: covid19_rc32_4pcs_complete_0.25mm_PET_MK3SMMU2S_5h33
Recv: SD printing byte 3766/19015124
Recv: 00:03

I'm not sure if I clearly said before that I haven't find this issue once I was starting print from SD card directly without preheating for cleaning.

Unfortunately, the first try to duplicate it today morning wasn't successful. I will keep trying once I could have it under control and monitoring

[precision]

Correct ~/.octoprint/logging.yaml doesn't exist by default, you will have to create the file.

But before that, let me see if I have the flow of what is happening correct. This may well be working as intended.

What I think might be happening is that octoprint is reporting is_printing() correctly once the print actually starts from the SD card, but sometime elapses between "Starting print from SD" and "Printing from SD" in which the timer fires because 10 minutes has elapsed since you preheated the printer and the plugin shuts everything down.

If you manage to capture a log of it shutting things down I should be able to tell if this is the case.