Jogwheel + start of any gcode motion causes Following Error

(Mentioned it before within another thread)

I have an XHC-HB04 for a mpg with a physical jog wheel.  If you use the mpg jogwheel and press the axis go-home button that calls G0 Y0, it throws a Following Error.  It was pretty easy to hit this prob.  

Now if it's already running gcode, the jogwheel is locked out and there's no error.  But if you're turning the jogwheel and press anything that calls a gcode command or actually start a gcode file then you always get a Following Error.

2.7 didn't seem to have any prob with this.  Apparently 2.8 has a prob with jogging and  an interpreter command at the same time.  Granted, not much reason to hit a gcode command while moving, but for "go to axis home" it's not too unusual and Following Error is a REALLY ungraceful response.  

My mpg hal is in position mode, and does have a low pass filter so the motion is not jerky.   That does mean it will have some pending movement for a moment after stopping the wheel, so gating off the mpg jog counts when executing a command won't fix it.  I'm not sure if the lowpass is fundamental to this prob or not yet.

We are a makerspace with a very large user base, many are casual users who just pick it up for a project or two, most operate without supervision, so "just don't do that and you won't have a problem" isn't a robust solution.  

Any ideas?

I can verify that this is repeatable in Master
Probably what should happen on a mode change
out of manual mode is that any jogs in progress
should be aborted and then the TP should wait till
all motion is stopped before continuing.

You can't entirely "abort" motion instantaneously.  If the axes are moving at high speed and we get a G0 X0 Y0, it can't stop immediately.  It has to decelerate, which, again, means it can't run immediately.

So, 3 actions are possible- stop taking new jog motion, complete the motion you are doing, and/or running the g-code.

I'd say to just ignore any G-code command or Run command while the axes are in motion.  Caching so it acts on it after the fact sounds like trouble.  

Should it block the new jog motion if we're not caching the command.  The button press to say G0 X0 Y0 has come and gone and there is no ongoing basis to block motion.  Just like using the jogwheel while running g-code- that's not a fault that stops the g-code, it just ignores the jog command.

I'm picturing what would be best if this were a big crane that is slow to come to a stop, like 2 seconds.  If the jogwheel is spinning, hmm, I was first thinking it should just ignore the home command, but now I'm thinking it should block new jog commands, wait for the halt, then go home.  Or, I guess it's possible to replan the trajectory immediately.  e.g. we're jogging to the right in position mode, already in motion and the targeted position is 1m to the right, and the button G0 X0 Y0 would take us 5m further to the right.  Well, you wouldn't need to block the jogwheel and come to a stop at the 2m point only to start and accelerate again 3m further to the G0 X0 Y0 destination.  You could block the jogwheel steps and abort the current plan to move 1m to the right and stop, and instead take your current velocity vector and start a new plan to go to the G0 X0 Y0 point immediately.

I wonder where that would leave us if there were a true high analog jog device that, due to being analog, was always putting out small movements back and forth.  Such as a VR controller.  It's never at a complete stop, if it had to wait for that it'd never get it. 

Yeah, I'd say block additional jog, throw away the current position target, and make a new plan.  That might be pressing Run, so the gcode probably says go to a home position first and it will start doing that.  

Another case, you're manually jogging X and press a button that would move the Y somewhere.  Technically, it can do both with no conflict.  But I can't see a reason to DO that.  

Any idea what to do today to avoid this?  This simple combination of actions doesn't have a small effect like ignoring the G0 X0 Y0 button, it's a Following Error and that puts the system into Unpowered state.  That's gonna be confusing for a lot of people and makes it look janky and unreliable.  I'm wondering how far it goes- it seems unlikely people would hit RUN while still partly jogging, the most likely case would be hitting G0 (current axis) 0 while still in motion on the mpg specifically.  Since MPG pins are connected via HAL, naybe I could AND-gate that one with a "not in motion" pin.  What signal would make the most sense for showing the axis isn't doing motion that would cause the Following Error?

By "abort motion" I mean come to a controlled stop using the joint and axis motion constraints

It think is cleaner to just disable jog inputs, abort motion, and change motion mode when stopped.

This needs to be fixed in motion, not hal, but a hal workaround would likely need a delay
to allow motion to stop after jogging is disabled before changing modes

I'll give it a shot! But I have sucked at compiling so far. It took a long time to get my vfd compiled correctly. Or, well, how would installing this update from github work?  Be real specific what I need to do from the command line.  Explain it like I'm 5, please.  It has an internet connection.

I did test the old 2.7 install, spun the jogwheel and started pressing the mpg button that pulls a G0 ?0 for the current selected axis. The 2.7 just ignores the button and lets you use the jogwheel. That button only works if the axis is not in motion.  Only in 2.8 does it throw a Following Error.

I shall await with baited breath

Was the fix tested with all screens?
I've got a bug report on 2.8 that sounds like it might be caused by the mode change fix.
(collecting info at the moment)