Note that UBL has a tentacle in quick_stop to prevent it from purging remaining blocks when Map Control is turned on, so moves may continue to occur after quick_stop for purposes that are specific to Map Control.

That is only in the case of using the LCD Display to position the nozzle at a new mesh point. The whole intent is if the user is spinning the dial, we don't want the nozzle to trace through every mesh point. Instead, we cancel the current move and start heading towards the (currently) selected mesh point on the LCD Display. This allows a much more responsive edit session.

There should be no harm throwing out any queued motion commands so long as the next destination mesh point has been identified and a move to get there is submitted.

void Stepper::quick_stop() {
  #if ENABLED(AUTO_BED_LEVELING_UBL) && ENABLED(ULTIPANEL)
    if (!ubl.lcd_map_control)
      cleaning_buffer_counter = 5000;
  #else
    cleaning_buffer_counter = 5000;
  #endif

I suspect we can cut out this tentacle. (Or really... The special case for UBL's LCD Mesh Editing) I think we just need to flush the entire queue... And then make sure we queue up a single move that gets the nozzle to the currently selected mesh point.

For Map Control it could be safe to have cleaning_buffer_counter set to some smaller value, like 1 or 2. We definitely want to kill any blocks that might still be in the planner, because they won't chain properly to a block that's been stopped mid-move. The value 5000 leads to the Stepper ISR cleaning blocks for a full 1/2 second. It might be safe for Map Control purposes to set it to a smaller value, or it could still set cleaning_buffer_counter to 5000, but wait in a loop until movesplanned() is zero, and then set cleaning_buffer_counter to zero before adding the new move.

If cleaning_buffer_counter is made public then this can be done like so…

void _lcd_do_nothing() {}

  if (planner.movesplanned() > 1) { // if the nozzle is moving, cancel the move.  There is a new location
    stepper.quick_stop();
+   currentScreen = _lcd_do_nothing;
+   while (planner.movesplanned()) idle();
+   stepper.cleaning_buffer_counter = 0;
+   currentScreen = _lcd_ubl_output_map_lcd;
    set_current_from_steppers_for_axis(ALL_AXES);
    sync_plan_position();
    ubl_map_move_to_xy(); // Move to new location
    refresh_cmd_timeout();
  }

I see that 2.0.x and 1.1.x still don't match in several areas, most notably the ubl_height_adjust family of functions in ultralcd.cpp seem to be more modern and correct in the 1.1.x branch, and have not been ported to the 2.0.x branch.

@Roxy-3D I have one specific question regarding two lines. Which is more current and correct?

      const int ind = ubl_height_amount < 0 ? 6 : 7;
      strcpy_P(UBL_LCD_GCODE, PSTR("G29 P6-"));

…or…

      const int ind = ubl_height_amount > 0 ? 9 : 10;
      strcpy_P(UBL_LCD_GCODE, PSTR("G29 P6 C -"));

I believe this is more correct:

      const int ind = ubl_height_amount > 0 ? 9 : 10;
      strcpy_P(UBL_LCD_GCODE, PSTR("G29 P6 C -"));

The G29 P6 mesh adjust needs a 'C' constant to tell the command how much to shift the mesh up or down.

I see! So in that case I'll assume the UBL-oriented stuff in 1.1.x (ultralcd.cpp) is most up-to-date and add a commit to the 2.0.x PR to match them up.

I hope to know what the reason for #8700 , #8704 is.
I expected to have 0-1 moves in the buffer after the endstop hit. What we do now is a bit of overkill.
We tell the stepper interrupt to delete (BLOCK_BUFFER_SIZE - 1) lines. This will take a while because only one line is deleted at the time. While the stepper isr does its job the main program continues. After a planned endstop hit it normally waits until the buffer is empty (stepper.synchronize()) and begins to produce the next moves to back up, or whatever. These moves are planned and immediately deleted by the still in delete mode running stepper interrupt.
This behaviour was planned for the emergency stop to empty not only the planner buffer, but also all others. For that the high number.
Sorry, could not see that yesterday.
Same in #8691

A possible fix could be to set cleaning_buffer_counter to -planner.movesplanned() or to prevent from spliting the moves by my version of the patch.

Or

/**
 * Block until all buffered steps are executed or deleted
 */
void Stepper::synchronize() { while (planner.blocks_queued() || cleaning_buffer_counter) idle(); }

@AnHardt Since I reported #8704, is there anything I can do to help out here with code review or testing or etc? I'm not super-experienced with C family languages but I can get by - especially when I know what I'm supposed to be looking at.

Stepper::synchronize

The stepper synchronize idea seems good, but then there are cases where synchronize isn't guaranteed to be applied immediately after the endstop/probe move.

Here's one idea. We have room for more block flag bits. We could add an EXPENDABLE bit that indicates (for example) that the block comes from a split move. When cleaning_buffer_counter is set to a negative value then it will only throw away blocks marked as expendable and stop as soon as it hits a non-expendable block.