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.
Implements changes to LCD and encoder pins from
forums.reprap.org/read.php?110,716538,728278 and also sets
ST7920_DELAY_[1-3] to DELAY_2_NOP to be compatible with the slower LCD
Implemented synchronization message output for NanoDLP printers (nanodlp.com).
If optional feature is enabled in `Configuration_adv.h`, Marlin will ouput "Z_move_comp" string to serial after completing any G0/G1 Z-axis movements. This feature patched on previous versions(1.0) is used by NanoDLP to synchronize Z-axis movement with projector exposure in DLP stereolithography printers.
Also... Doing a 'Direct Commit' to see if that is 'acceptable' for small changes like this. I want to look at the commit history and see how the logs handle this type of change.
* Fix thermal protection documentation.
Even before the recent thermal protection changes, the documentation of
the thermal protection feature in the config files did not match the
implementation. I fixed the documentation and reconciled the M303
implementation with the documentation.
* Applied documentation changes to sample config files
* Renamed hysteresis to watch_temp_increase
* Added gcodes back into documentation.
* Fix G26's circle drawing...
This mostly catches the bugfix-v1.1.x branch up to bugfix-v2.0.0
I'll have to do something similar to get bugfix-v2.0.0 caught up to
bugfix-v1.1.x
* only use planner.leveling_active if appropriate
* Initial conflict resolution
All previous items resolved:
- Use of ELAPSED() on timer code
- Switch to use of defer_return_to_status=true as much as possible
- Update & Clean Up of Max7219 routines
* Resolve non-SD case in ultralcd.cpp
