So, octoprint users were consistently hitting an issue where the printer would switch to relative mode and die from over extrusion protection. Or turn off the heaters. You know, the fun sort of stuff that makes a 3d printer a little more useful than a boat anchor. Solution? A bluepill. I keep a handful around at any time, and they have a couple of great properties:

1. They run on 3.3v logic, meaning I don't need to spend time shifting levels.

2. Two free hardware UARTS. What's not to like about that?

3. USB! A nice, pretty USB Mini connector, which means that all I really need to diagnose protocol issues is a set of jumpers. Wire one Serial to the Mini's mainboard, one to the display, serial + GND and just a scratch of Arduino code, and we have a cheap protocol sniffer. 

As I noted, nothing seemed to repro on my hardware, except for the delta.

And if I had just paid a little more attention to waht my eyes were telling me, I wouldn't have needed to do any protocol sniffing.  See, if you simply watch a late run V2 or delta's screen while issuing a temperature wait command. Go ahead, I'll wait.

Back already?

Yes, it switches to a screen I call the build screen, because the command that takes the mini to it is "{SYS:BUILD}"

This screen does NOT result in a timeout. Without a file call, it won't show you the file being printed, but that doesn't matter - what matters is that it doesn't time out. 

Fixing this required extending the malyan_lcd code to support status prints. We can't possibly display them but we can check to see if they match the heating messages (using their string constant names) and issue the SYS:BUILD command there.

I've pushed a set of changes for this, but there's a few caveats:

It's essential that at least one temperature wait comand be used. M140, M109, whatever wait method you want in your slicer. Don't do that? Prepare for timeouts. Also, thanks to a project contributer, speed adjustment should work better. Note that if you are using an early V1, this may break speed adjustment, as I'm near certain there's a bug in V1 LCDs where it sends the wrong command while adjusting feedrate. If so, this fix breaks that, but I don't have my early V1 LCD anymore. I'll watch reports and see if it crops up. If so, I can make adjustments.

Happy printing...