Virtual Printer doesn't stop sending progress messages on cancel

[jneilliii]

The problem

Noticed while working on a plugin that a SD card print cancelled continues to report printing messages with a frozen bytes/filesize report

Did the issue persist even in safe mode?

Yes, it did persist

If you could not test in safe mode, please state why ("currently printing" is NOT an excuse!)

No response

Version of OctoPrint

1.9.3

Operating system running OctoPrint

OctoPi 0.18

Printer model & used firmware incl. version

Virtual

Browser and version of browser, operating system running browser

Chrome Version 120.0.6099.129 (Official Build) (64-bit)

Checklist of files to include below

• Systeminfo Bundle (always include!)
• Contents of the JavaScript browser console (always include in cases of issues with the user interface)
• Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
• GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)

Additional information & file uploads

octoprint-systeminfo-20231226005332.zip

[Gina Häußge]

I think this is actually a case of "works as intended".

As there's no actual command to cancel an SD print that's available on all firmware variants[1], or a way to deselect a file from SD, but rather just a M25 to pause it (and then you just never resume it), this is also what's used when you cancel an SD print from within OctoPrint. But when you just pause, the SD file is technically still open to print (and an M24 would resume).

I could of course switch the auto report to report "Not SD Printing" while the SD job is paused, but from a quick look into at least the current Marlin source that would not mirror common firmware behaviour, which would actually behave like the virtual printer does now:

void CardReader::report_status() {
  if (isPrinting() || isPaused()) {
    SERIAL_ECHOPGM(STR_SD_PRINTING_BYTE, sdpos);
    SERIAL_CHAR('/');
    SERIAL_ECHOLN(filesize);
  }
  else
    SERIAL_ECHOLNPGM(STR_SD_NOT_PRINTING);
}

Ironically, that isn't even what's supposedly implemented now in the Virtual Printer, as there's a bug currently that causes this (IMHO correct) behaviour by sheer coincidence, even though the implementation was meant another way. In any case, I'll fix that.

What you are actually seeing here is that the printer was still in heating up mode, which is why the state was still stuck in Cancelling until the Cancel commands could be sent over. Easily reproduced by starting to print a file that contains a blocking heatup and cancelling during that. Doesn't even have to be on SD, while the blocking heatup is going on the printer won't accept anything but emergency stops (unless M108 is supported, in which case OctoPrint will attempt to send that if configured accordingly).

So, first of all, things looked stuck as you were still in a blocking heatup. And then the auto reporting behaved correctly and kept reporting the state.

[1] There's apparently an M524, but that seems to only be supported by Marlin 2.0+, Repetier and Druid and thus cannot be relied on here.

[Gina Häußge]

Fixed the aforementioned wrong logic that still lead to the right outcome thanks to a bug.

[jneilliii]

Thanks Gina, didn't even think of the heat up blocking here. Sorry for the noise.