Repair display throttling

[AnHardt]

Some time ago @thinkyhead asked in a comment if my display throttling code is still working. After a very brief look i answered it would be still in place, but a bit of debug code would show if it still works.
I suggested to look at the numbers in https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/lcd/ultralcd.cpp#L986.
Since up to now, seemingly no one else did and i was away from my equipment, i did it now.
And, who wonders - it did not work. max_display_update_time seems to have realistic values, but during print planner.block_buffer_runtime() grew more and more. Consequently there was always enough time in the planner buffer to allow a display update.
The subtraction of the time for the running block did not work because block->segment_time_us was never set. All operations in the planner worked on the local segment_time_us.

[Roxy-3D]

@AnHardt I wonder if this corrects an error causing layer shifts in the v2.0.0 code? One thing I found was if I scaled the F/R down to 70% or so on the LCD Panel, I would never see a layer shift. One explanation might be the stepper motors did not have to work as hard and had enough torque to do what they were supposed to do.

But another explanation might be there were not CPU cycles left (at 100% feed-rate) and something was losing position or moves within the Planner:: or Stepper:: stuff.

With this fix in place, it will be interesting to see if we there are less layer shifts in the v2.0.0 code. If this does eliminate some layer shifts, that might be more evidence we have an error in the code when the CPU is fully saturated and there are no spare cycles. I don't know exactly where that error would be. But it does appear to me like having no spare cycles aggravates the problem.

[AnHardt]

I wonder if this corrects an error causing layer shifts in the v2.0.0 code?

I don't think so. If a display update is done at a (timely) too short buffer, the buffer should simply run dry, and we see a unwanted variation in speed (stutter).

[thinkyhead]

I have a naive suggestion as an alternative to this throttling technique:

• If the G-code buffer isn't "mostly full" then delay the screen update until it's "mostly full" again.

[AnHardt]

The number of segments in the buffer does not say anything about if the buffer will be empty after a display update or not. For that the time a segment needs to be stepped is to different. (280mm diagonal infill vs. minimal segment length (7 steps)).
The relation (% of buffer usage) tells us even less.

Currently the problem seems to be that, the times for (partial) display updates are less uniform than before. Some updates seem to last much longer than the status screen updates. From the reports code around "pause" messages is most suspicious to me.

The other wheel we can turn a bit is faster recovery from exceptional long lasting display updates.

   // This runs every ~100ms when idling often enough.
    // Instead of tracking changes just redraw the Status Screen once per second.
    if (on_status_screen() && !lcd_status_update_delay--) {
      lcd_status_update_delay = 9
        #if HAS_GRAPHICAL_LCD
          + 3
        #endif
      ;
      max_display_update_time--;
      refresh(LCDVIEW_REDRAW_NOW);

1. We could make larger steps then -1

2. We could drop the on_status_screen() condition.

3. Currently has this effect: If you have the impression the status screen is not updating and press the encoder button to verify, you are entering the main menu without seeing that (when really delaying). The max_display_update_time is effectively not decreased anymore until menu_timeout returns to the status-screen, or you click a second time to return to the status screen (what you again will not see).

A workaround could be to delay and measure only status screens. In the menus the user expects immediat response anyway. Not touching the encoder while printing seems to be learnable.

Finding the reasons for long(er) lasting run_current_screen() calls, or any measured delays, should have priority. Maybe a additional ms = millis(); closer before run_current_screen() could have a positive effect.

[AnHardt]

#15414
#15169
#15293