Messages queued when printing is paused cause delay when resuming print

[TheAssassin]

This occurred on a Prusa MK3S with the latest firmware 3.13.2.

When the printer pauses before a layer due to a filament change, the plugin's messages apparently queue up. When you leave the printer for an hour or two, a sizable amount of old messages can end up in said queue. When you then resume the print, the print head moves back onto the object, but the printer now needs to show all the messages first before it can actually resume. This causes some defects on the surface the print head moved to.

The reason might be that the display shows a printer-generated message rather than the messages the plugin sends to it. Obviously, the gcode is not processed in the meantime. I'd suggest to either send a single message, then wait for the print to resume (I think Marlin resp. Prusa's fork send gcode to signalize that nowadays).

[tpmullan]

That is interesting. Looking at the code here I would think it would not generate any messages since the layer is not changing. But if there are things that trigger a message being sent and the printer firmware decided to ignore it then process it later, I don't really think that can be easily addressed in the plugin. The best we could do is somehow find out a filament change is happening and disable all messages from the plugin.

If you want to take a crack at it, PRs are always welcome.

[TheAssassin]

As far as I can see, the plugin is sending periodic messages using a round-robin scheme on a list of templates. I use it in combination with DetailedLayerProgress, if that matters. I could imagine that OctoPrint does not take notice of the printer pausing; it just does not fetch any more gcode in this scenario. The print is paused by the printer due to gcode, not OctoPrint.

Edit: I could imagine that a case needs to be added, presuming that OctoPrint offers such an option?

[ggppjj]

This also happens if a Prusa MMU3 causes a print pause, messages queue up while the printer awaits user intervention and it plays back everything very fast after heating the head and returning to the print but with an appreciable delay that increases as the time spent not clearing the issue increases it pauses with the head on the print until it clears the buffer. In my case, I had a filament change cause a user intervention request after I went to bed, and all of the hours worth of progress messages after it paused had to play before it resumed the print. I personally will be happy to recreate this scenario and provide any logs as I am able, but I don't think I currently have the skillset to debug this from the perspective of someone who has never messed with Octoprint plugin code to any reasonable degree in the past to be of much help here otherwise. I've had to disable the plugin for the time being to avoid late-print failures caused by otherwise recoverable issues.