Hi guys,

using the latest bugfix-1.1.x, I enabled EMERGENCY_PARSER to be able to use M108 in headless mode, via host, to resume from M600 pause.

The issue I am seeing now is that on some hosts (e.g. Pronterface) the firmware halts on M109 heatup. It heats up, displays "paused for user" and holds the temperature. Only if I send M108 the print starts (since that sets wait_for_user to false I suppose).

Since Pronterface caused this issue and OctoPrint did not, I noticed that OctoPrint uses the recommended way of M155 for temperature polling while Pronterface floods the printer with M105. This seems to cause a lock up on the M109 heating period.

Is there any way of preventing those commands of causing the firmware to wait for user input?

Thanks in advance!

Ok, figured it out: The constant M105 commands seemed to fill the serial buffer while wait_for_heatup was true. When the heating finishes, it seems like M1 is executed. I suppose there is a chance of two bytes getting cut off when the buffer is full so that M105 becomes M1.

Anyways, adding flush_and_request_resend() to the end of the M109 and M190 loops fixes this issue. Hope it's not too dirty of a workaround.