@marcio -- Is there a reason why HOST_KEEPALIVE_FEATURE is not being used?
I have been seeing some "communications timeouts" in Octoprint. It expects an "ok" within defined period (default 25 seconds), otherwise it thinks communication is overdue -- even if temperature auto-reports are still being received. Note: I am using 184.108.40.206 with a Lulzbot Mini Gladiola, but I checked the 220.127.116.11 source and Host_Keepalive_Feature is still not enabled).
Examples where this causes a problem....
(1) During bed cooldown, which can take several minutes, Octoprint doesn't see an OK acknowledgments for the M190. So even though temperature auto-reports are coming every 2 seconds, it throws a comm timeout error.
(2) Several long/slow G1 extrusions are queued and acknowledged, followed by a "G92 E0". The "G92 E0" doesn't appear to send an acknowledgement until actually processed, so the "OK' response for it is held until all those queued G1's are physically finished. This can easily exceed Octoprint's expectation that an OK get received for that G92 within 25 seconds.
The HOST_KEEPALIVE_FEATURE was, of course, designed specifically to handle this -- letting the firmware tell the host "I'm still working on that...." so the host doesn't conclude there is a problem when acknowledgement is delayed. I enabled HOST_KEEPALIVE_FEATURE and recompiled (18.104.22.168), and the "busy: processing" messages that it generates eliminates the timeout complaints from Octoprint.
Can this feature be enabled in future builds? Or is there a conflict (perhaps with Cura-LE) that has prevented you from enabling it?