PronterFace keeps sending M105 requests during long operations like G29 P1, G29 P2, G29 P4 and G26. The serial buffer fills up before the operation is complete. The problem is, a corrupted command gets executed. It is very typical for the M105 to turn into a M1 (actually... M1M105 is typical).
This causes the printer to say "Click to resume..."
This is a temporary fix until we figure out the correct way to resolve the issue.
More work needed for G26.
The changes to ultralcd.cpp for is_lcd_clicked() did not encompass the
full functionality of UBL's G29 P1, P2 and P4. It also broke G26's
ability to abort in several of its phases.
This is the first pass at fixing the problem. It has been tested for
correctness for several hours but more testing needs to be done.
There may be a few follow up patches to finish covering all the corner
cases, but right now I need to merge this before any conflicts show up.
Some of these changes will need to be moved over to the bugfix-v2.0.0
branch. That will happen a few days from now.
Reverse engineered from the unpublished firmware from Creality,
inferring the base version and configuration they used. The basis is
the firmware version from "Jul 31 2017 10:16:30". Configurations were
found by seeing what code was compiled into the firmware, and
constants used there.
They used Marlin 1.0.1, because
* 1.0.0 had very different serial output in `setup()` and overall
code structure.
* 1.0.2 changed the `VERSION_STRING` to include a leading space,
and `lcd_init` uses `SET_INPUT` instead of `pinMode`.
For U8Glib, a version between 1.14 and 1.17 was used, because
* 1.12 didn't have the extra speed argument to u8g_InitCom.
* 1.13 didn't have the soft reset instruction for UC1701 initialization.
* 1.18 has a new directory structure.
Quirks
* The value of PID_dT hints that F_CPU is 20M, but MarlinSerial.begin
suggests it's indeed 16M (and the board uses 16M). Left at 16M for now.
* The LED and DOGLCD_CS are on the same pin.
