- Fix: When "100.0" changes to "99.0" the LCD shows "199.0"
- Use 2 rows if needed on character LCD, (allowing longer labels…
Germany, et. al.)
- Known issue: A certain length label combined with a certain value
drawing function could, for example, display 99.0 on 1 line, but 100.0
on two lines. Workaround would be to pass a nominal value size argument.
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.
* Unify M600 and M125 pause features
* Cleanup per thinkyhead's comments
* Rename filament_change_menu_response to advanced_pause_menu_response
* Include HAS_BED_PROBE in QUIET_PROBING
* Update gMax example file
* is_idle() is out of scope without the braces
* Convert FT-i3-2020 to Advance Pause names...
* Allow pause even if not printing
`ftostr62sign()` is used only when displaing/editing
Steps/mm. A sign is not needed - the value is always positive.
Because the number part is long there is no't much place for the values name.
With this PR the is one more char for the name possible.
Currently we draw and send the screens for a graphical LCD all at once.
We draw in two or four parts but draw them directly behind each other.
For the tested status screen this takes 59-62ms in a single block.
During this time nothing else (except the interrupts) can be done.
When printing a sequence of very short moves the buffer drains - sometimes until it's empty.
This PR splits the screen update into parts.
Currently we have 10 time slots. During the first one the complete screen is drawn. (60,0,0,0,0,0,0,0,0,0,0)
Here i introduce pauses for doing other things. (30,30,0,0,0,0,0,0) or (15,15,15,15,0,0,0,0,0,0)
Drawing in consecutive time slots prevents from lagging too much. Even with a 4 stripe display all the drawing is done after 400ms.
Previous experiments with a even better distribution of the time slots like
(30,0,0,0,0,30,0,0,0,0) and (15,0,15,0,15,0,15,0,0,0) did not feel good when using the menu, because of too much lag.
Because of the previous PRs to speed up the display updates and especially reducing the difference between drawing 2 or 4 stripes,
it now makes sense for the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER to go from 2 to 4 stripes. This costs about 1-2ms per complete
screen update, but is payed back by having partial updates lasting only the half time and two additional brakes. Also ~256 byte of
framebuffer are saved in RAM.
13:45:59.213 : echo: #:17 >:13 s:30; #:16 >:13 s:29; S#:33 S>:26 S:59
13:46:00.213 : echo: #:16 >:14 s:30; #:17 >:13 s:30; S#:33 S>:27 S:60
13:46:01.215 : echo: #:17 >:13 s:30; #:16 >:13 s:29; S#:33 S>:26 S:59
13:46:02.215 : echo: #:16 >:13 s:29; #:16 >:14 s:30; S#:32 S>:27 S:59
13:46:03.214 : echo: #:17 >:13 s:30; #:17 >:13 s:30; S#:34 S>:26 S:60
13:46:04.214 : echo: #:16 >:13 s:29; #:16 >:14 s:30; S#:32 S>:27 S:59
13:46:05.212 : echo: #:16 >:14 s:30; #:17 >:13 s:30; S#:33 S>:27 S:60
13:46:06.212 : echo: #:17 >:13 s:30; #:16 >:13 s:29; S#:33 S>:26 S:59
03:30:36.779 : echo: #:8 >:7 s:15; #:10 >:7 s:17; #:8 >:6 s:14; #:8 >:7 s:15; S#:34 S>:27 S:61
03:30:37.778 : echo: #:8 >:6 s:14; #:10 >:7 s:17; #:9 >:7 s:16; #:8 >:6 s:14; S#:35 S>:26 S:61
03:30:38.778 : echo: #:8 >:6 s:14; #:11 >:7 s:18; #:8 >:6 s:14; #:8 >:7 s:15; S#:35 S>:26 S:61
03:30:39.777 : echo: #:8 >:6 s:14; #:10 >:7 s:17; #:8 >:8 s:16; #:8 >:6 s:14; S#:34 S>:27 S:61
03:30:40.780 : echo: #:8 >:6 s:14; #:11 >:7 s:18; #:8 >:6 s:14; #:8 >:6 s:14; S#:35 S>:25 S:60
03:30:41.780 : echo: #:9 >:6 s:15; #:10 >:7 s:17; #:8 >:6 s:14; #:9 >:6 s:15; S#:36 S>:25 S:61
03:30:42.779 : echo: #:8 >:6 s:14; #:10 >:8 s:18; #:8 >:6 s:14; #:8 >:6 s:14; S#:34 S>:26 S:60
03:30:43.778 : echo: #:9 >:6 s:15; #:10 >:7 s:17; #:8 >:7 s:15; #:9 >:6 s:15; S#:36 S>:26 S:62
#: draw a stripe
>: transfer a stripe
s: sum of of draw and transfer for one stripe
S#: sum of draws for a complete screen
S>: sum of transfers for a complete screen
S: time to draw and transfer a complete screen
João Brázio