Last modified: 2024-02-13 20:37:55
< 2024-02-07 2024-02-13 >I realised that I actually have a couple of different issues with the jog controller.
Firstly I need to clarify what behaviour I actually want.
And secondly I need to work out how to implement that using the Grbl interface.
I should make a proof-of-concept that lets the keyboard control a moving object with the kind of control I want, and then work out how to make that operate Grbl instead of operating the object directly.
It seems self-evident that every axis should be controlled independently, however this is slightly challenging because the "jog cancel" command cancels all axes.
Each axis can be in one of 3 states:
Assuming the axis starts out stationary, when you first press the arrow key it starts an incremental jog. If you hold it down long enough to trigger the key repeat, then it switches to continuous jog. If you then let go while it's in continuous jog, it needs to have travelled at least the distance of the incremental jog. Similarly if you tape the arrow key a bunch of times, then go continuous jog, then stop, it needs to have done at least the incremental jogs you asked for.
What if you tap both directions a bunch of times, and continuous jog in both directions a bunch of times, and then do some more incremental jogs in both directions? I think it needs to remember whether or not it passed the summation of the incremental jogs. If it has gone past the point that the incremental jog was commanded to go to, then when you let go it can just park wherever it is. If it has not yet gone past the incremental target, then it should just finish going to the incremental target when you let go. What if it passes the incremental target in the course of decelerating? Then just stop wherever it stops.
Once it has come to a standstill it can reset the incremental target to the place it stops at, so that when you resume incremental jogging it works as expected. It's at a standstill if the magnitude of the velocity is below some epsilon for say 100ms. Ah, but the bug with this was that the instant you send a jog command, the velocity is 0, so it resets your jog target immediately. So it needs to be both stationary and uncommanded for 100ms.
So when a key is released we need to send a jog cancel, and then send a jog command to resume the incremental jog for any axes that have not already reached/passed their incremental target.
So state we need, per axis, is: * last time a jog of any kind was commanded * last time a movement of any kind was observed * incremental jog target * actual jog target (updates periodically when continuous jogging) * whether the incremental target has been met/passed * whether the continuous jog key is held
Then when a key is pressed, we update the incremental jog target for that axis; if the axis is currently moving, then we update the actual jog target to match the incremental jog target only if the new incremental jog target is further than the actual jog target in the same direction as it is currently moving. We unset the flag, to say it is not continuous jogging (but probably doesn't matter).
When a key is held, we set the flag to say it is continuous jogging.
When a held key is released, we unset the flag to say it is continuous jogging, send an all-axis jog cancel, and then send a new jog command to resume the incremental jogs for any axes that have not met their incremental jog target, and to resume the continuous jog for any axes that are continuous jogging.
< 2024-02-07 2024-02-13 >