millis_t is long - divisions take for ever.
Return a kind of millisecond instead of microsecond -
divided by 1024 instead of 1000 for speed. (2.4% error)
That does not matter because block_buffer_runtime is
already a too short estimation.
Shrink the return-type.
The target here is to update the screens of graphical and char base
displays as fast as possible, without draining the planner buffer too much.
For that measure the time it takes to draw and transfer one
(partial) screen to the display. Build a max. value from that.
Because ther can be large differences, depending on how much the display
updates are interrupted, the max value is decreased by one ms/s. This way
it can shrink again.
On the other side we keep track on how much time it takes to empty the
planner buffer.
Now we draw the next (partial) display update only then, when we do not
drain the planner buffer to much. We draw only when the time in the
buffer is two times larger than a update takes, or the buffer is empty anyway.
When we have begun to draw a screen we do not wait until the next 100ms
time slot comes. We draw the next partial screen as fast as possible, but
give the system a chance to refill the buffers a bit.
When we see, during drawing a screen, the screen contend has changed,
we stop the current draw and begin to draw the new content from the top.
`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
lcd_update can take so much time that the block buffer gets drained if
there are only short segments. This leads to jerky printer movements for
example in circles and a bad print quality.
This change implements a simple check: Only if the block currently
executed is long enough, run lcd_update.
This also means the printer will not show actual values on the LCD nor
will it respond to buttons pressed. A option that keeps the menu
accessible is also available.
Aditionaly, slow down if a block would be so fast that adding a new
block to the buffer would take more time. In this case, the buffer would
drain until it's empty in worst case.
Always define MIN_Z_HEIGHT_FOR_HOMING even if 0
Always make a potential rise to `home_offset[Z_AXIS]` possible in G28.
Get rid of some very ugly constructs in MBL (ultralcd.cpp).
Includes:
*firmware version / branch / date.
*extruder count
*board information (name, serial details, power supply type)
*thermistors (names, min/max temperatures)
*printer statistics (PRINTCOUNTER details)
Thanks to @thinkyhead for contributions.
The LCD menu items for SD printing pause/stop have been updated to control
also the print job timer. This commit also fixes a small output bug with
M78, the failed print counter was displaying the wrong value.
Speedup sreen update delay
and correct a comment.
A module division by 10 is slooooow. (powers of 2 are fast - but then you can AND a bitmask with the same result)
Follow-up the PR #3643(Temperature singleton)
・Change from fanSpeedSoftPwm[0] to thermalManager.fanSpeedSoftPwm[0] in planner.cpp
It fix compilation error when FAN_SOFT_PWM is enabled.
・Remove declaration of setExtruderAutoFanState() in temperature.h
Because that function was abolished.
・Change from babystepsTodo to thermalManager.babystepsTodo in ultralcd.cpp
It fix compilation errors when BABYSTEPPING is enabled.
Additional follow-up the PR #3631(Encapsulate Stepper, Planner, Endstops in singleton classes)
・Change from abort_on_endstop_hit to stepper.abort_on_endstop_hit in endstop.cpp, Marlin_main.cpp, and ultralcd.cpp
・Add include path to cardreader.h and temperature.h in endstop.cpp(for CardReader class and disable_all_heaters())
It fix compilation error when ABORT_ON_ENDSTOP_HIT_FEATURE_ENABLED and SDSUPPORT are enabled.
・Change from digipot_current() to stepper.digipot_current() in Marlin_main.cpp
・Change from digitalPotWrite() to stepper.digitalPotWrite() in Marlin_main.cpp
It fix compilation errors when HAS_DIGIPOTSS is enabled.
・Change from microstep_mode() to stepper.microstep_mode() in Marlin_main.cpp
・Change attribute of microstep_mode() from private to public in stepper.h
・Change from microstep_readings() to stepper.microstep_readings() in Marlin_main.cpp
・Change from microstep_ms() to stepper.microstep_ms() in Marlin_main.
It fix compilation errors when HAS_MICROSTEPS is enabled.
When setting the bed temp via M140/M190 if the thermistor does not read an increase of WATCH_BED_TEMP_INCREASE degrees by WATCH_BED_TEMP_PERIOD seconds then it will throw "Error:Heating failed, system stopped! Heater_ID: bed" and call the kill() function.
Conflicts:
Marlin/Configuration_adv.h
AnHardt