Do not end motion on jog cancel

[breiler]

This is an attempt to fix a problem with jog cancel on multiple small jog commands. It will cause the machine to abruptly stop, not taking the deceleration into account. The same problem does not exist on classic GRBL or grblHAL.

I have tried debugging the jog cancel by adding extra logging to these functions:

static void protocol_start_holding() {
    if (!(sys.suspend.bit.motionCancel || sys.suspend.bit.jogCancel)) {  // Block, if already holding.
        sys.step_control = {};
        if (!Stepper::update_plan_block_parameters()) {  // Notify stepper module to recompute for hold deceleration.
            log_info("End motion")
            sys.step_control.endMotion = true;
        } else {
            log_info("Don't end motion")
        }
        sys.step_control.executeHold = true;  // Initiate suspend state with active flag.
    }
}

// Called by planner_recalculate() when the executing block is updated by the new plan.
bool Stepper::update_plan_block_parameters() {
    if (pl_block != NULL) {  // Ignore if at start of a new block.
        log_info("Planning block available");
        prep.recalculate_flag.recalculate = 1;
        pl_block->entry_speed_sqr         = prep.current_speed * prep.current_speed;  // Update entry speed.
        pl_block                          = NULL;  // Flag prep_segment() to load and check active velocity profile.
        return true;
    }
    return false;
}

When canceling a long jog command such as this, the deceleration works as intended:

> $J=G21G91X-100F2007
ok
> Jog cancel
INFO: Planning block available
INFO: Don't end motion

However when canceling multiple commands it doesn't see the planning block and will therefore set the endMotion=true which will cause the abrupt halt:

ok
> $J=G21G91X0.335F2007
ok
> $J=G21G91X0.335F2007
ok
> $J=G21G91X0.335F2007
ok
> $J=G21G91X0.335F2007
ok
> Jog cancel
INFO: End motion

My interpretation is that when doing a jog cancel we never want to do a endMotion, this PR has therefore collected the cancel logic to its own jog-cancel-function.

There is another problem where trying to issue a feed hold command while jogging which will make the controller unresponsive. This PR will not fix that problem, but it will at least not get worse.

[bdring]

I was able to fix the hold from motion in issue #1410 with this change

@@ -485,7 +485,8 @@ static void protocol_start_holding() {
     if (!(sys.suspend.bit.motionCancel || sys.suspend.bit.jogCancel)) {  // Block, if already holding.
         sys.step_control = {};
         if (!Stepper::update_plan_block_parameters()) {  // Notify stepper module to recompute for hold deceleration.
-            sys.step_control.endMotion = true;
+            //sys.step_control.endMotion = true;
         }
         sys.step_control.executeHold = true;  // Initiate suspend state with active flag.
     }

It could be cleaned up by just calling Stepper::update_plan_block_parameters() without the if

I was only able to reproduce the issue by running the gcode provided in the issue. I think it creates a lot of planner activity with constant G2 arc.

I'll do some more testing.

[bdring]

@breiler It looks like the motion hold is working. Is the jog cancel working for you? It works for me. I tried using multiple jogs from the pendant encoder and canceling them.

[breiler]

@bdring, yes it works fine with jogging using these latest code changes.