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.
Microstepping Pins (reverse engineered at V1.4)
Some new batches have the HR4982 (Heroic) instead of the A4982 (Allegro) as stepper driver. While most of the functionality is similar, the HR variant obviously doesn't work with diode smoothers (no fast decay). But the Heroic has a 128 µStepping mode where the A4982 is doing quarter steps (MS1=L / MS2=H). To achieve comfortable tests with the M350/M351 commands, the following definitions have to made.
G26 uses logic that looks like:
```
ex = _GET_MESH_X(i + 1) - (SIZE_OF_INTERSECTION_CIRCLES - (SIZE_OF_CROSSHAIRS));
```
The Bi-Linear macros need parenthesis to work correctly.
Example Configuration.h files are not updated yet. You need to cross
your settings over to the default Configuration.h file in the \Marlin
directory. (UBL_G26_MESH_VALIDATION enablement has moved to a new
location in the file.)
This is a non-intuitive change. @oldmcg says in this post https://github.com/MarlinFirmware/Marlin/issues/7572#issuecomment-340641207 that using DELTA_PRINTABLE_RADIUS is better than DELTA_PROBABLE_RADIUS for setting the probe limits. This is because the automatic probe code checks all locations for being reachable by the probe prior to doing the probe.
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 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
* use reduced sized font for some languages
* Fit Portuguese language files to existing scheme
* Rename language_pl-DOGM.h to language_pl_utf8.h
* Rename language_pl_utf8.h to language_pl-DOGM.h
* Update dogm_font_data_ISO10646_1.h
* Update dogm_font_data_ISO10646_1.h
* Add Max7219 LED Matrix Debug Support
The Max7219 8x8 LED Matrix's are very helpful for debugging new code.
And for that matter, just trying to maximize printer settings without
causing stuttering.
The displays are very inexpensive (under $2.00 with shipping) and
provide a lot of help when trying to debug complicated code.
* Try to keep Makefile up to date.
Probing with the effector in the printing area, but an eccentric probe (e.g. allen key) outside it but still touching the bed gives meaninfull information for calibration. Since calibration is most accurate when probing as close to the towers as possible the testing was way to restrictive hence this fix.
Original Mesh Bed Leveling replacement put at top of UBL Menu Options to
help facilitate the removal of the Original Mesh Bed Leveling.
Radar display (and control) of the UBL Interactive Mesh Editing.
* Save up to 94 bytes of RAM on 20x4 LCD Display machines
Moved the custom screen characters out of RAM into Program Memory. With
SD-Card support and the Progress Bar enabled, this saves 94 bytes of RAM
memory.
This was tested using the example_configurations/FolgerTech-i3-2020
files. So a couple small changes to those files snuck into this Pull
Request.
Probably... We can find similar savings in the Graphics LCD code it we
comb through it. And if so... That is the place we really need to
save RAM memory!
* Tidy up white space and indentation
1138-4EB
Christopher Reimer
Project-J²
Bob-the-Kuhn
Roxy-3D
karkla
dot-bob
LVD-AC
Roxy-3D
dot-bob