2024-01-19

Last modified: 2024-01-20 10:02:27

G-code sender

While it's too cold to work in the garage I'm going to try and make some good progress on the g-code sender.

So the plan today is to review the list of "modes" I wrote the other day, then implement the most important of the components. Which I think is:

• machine state view (status, DRO, computed Vel per axis, feed rate, spindle speed, alarms, probe state, active G/M codes, buffer sizes)
• ui mode name
• some hint to ui key shortcuts
• MDI history
• jog status

I wanted a computed DTG, but I'm not sure how feasible that is. By looking at the size of the planner buffer we might be able to know which line Grbl is currently working on? Not worth it for now obviously.

Here is a collage of screenshots from other software, for inspiration:

I actually think UGS (top left) is one of the clearest. I don't need the axis labels to also zero out the value. I don't need the secondary number underneath.

I'm having trouble getting jogging work as I want. Here are the facts:

• You ask for a jog moving by sending $J= and then the coordinates you want Grbl to jog to. For an incremental jog you can put G91 at the start, which in this context is not sticky.
• If you send too many commands then the input buffer fills up and Grbl won't process anything else at all! Even if the input buffer contains newline characters and you stop stuffing more into it.
• You can cancel an in-progress jog by sending 0x85 (Jog Cancel). This does a "feed hold" on the current jog movement, and flushes all jog movements out of the input buffer, aborting the current jog.
• Gio gives you keyboard input as Press and Release events. But in the case of a key held down, you get a continuous stream of Release and Press in the same frame, instead of just a single Press.
• I want to support usage of the keyboard to drive multiple axes at a time, including by holding down multiple keys and releasing only a subset. So you could move diagonally "up+left", then release "up" and it would abort any pending "left" movement but continue moving "up".
• I want to allow continuous jogging of one axis with simultaneous incremental jogging of another.
• I want continuous holding of opposing keys to result in no action.
• I do not want to recreate the UGS bug where you stop continuous jogging and it comes to a stop but then starts up again.

So we have 2 jog modes: incremental, and continuous, and we need to monitor the event stream to work out when we want to switch to continuous jogging (I think this is if there is a Release of a key followed by a Press of the same key, in the same frame).

In incremental mode we send a single incremental (G91) jog in response to each Press event, and we never send a Jog Cancel.

In continuous mode, we send a new incremental jog automatically, on some recurring timer, with an increment sufficient that Grbl won't have started decelerating before we send the next command. And when we detect that the key has been released, we send a Jog Cancel and cancel the timer.

So that will handle single-axis incremental and continuous jogging. The issue is how to handle multiple axes? I think if we detect that a key has been released, but some are still pressed, then we send a Jog Cancel, but immediately trigger the timer, so we continue sending jog increments, but only for the active axes.

I think there is no downside to making the continuous jog increment enormous, and that way we don't need the timer to run so frequently.

If you are doing a continuous X jog, and you start an incremental Y jog, and then you let go of the arrow key for the X jog, then the Jog Cancel will also cancel the incremental Y jog, which is not what you want.

OK, from reviewing https://github.com/gnea/grbl/blob/master/doc/markdown/jogging.md it seems like I really need to be tracking the jog state more closely. I am sending G91 incremental jogs because that's what UGS does, but I already know that I am not particularly convinced by UGS's jog control. I think what I should be doing instead is tracking the target position and sending absolute coordinates. This does mean I'll need to not allow interleaving of jog commands with ordinary commands, because then I'll get out of sync.

I also need to actually match up commands with "ok"/"error" responses. At the moment I'm looking at the planner buffer size to work out when my previous commands have been consumed, but that's not good enough.