Numbering 'ok' messages

[Moffy]

There seems to be a need for a distinction in some of the 'ok' messages. e.g. from 'Grbl v1.1 interface:
"Synchronization
For situations when a GUI needs to run a special set of commands for tool changes, auto-leveling, etc, there often needs to be a way to know when Grbl has completed a task and the planner buffer is empty. The absolute simplest way to do this is to insert a G4 P0.01 dwell command, where P is in seconds and must be greater than 0.0. This acts as a quick force-synchronization and ensures the planner buffer is completely empty before the GUI sends the next task to execute."

If the 'ok' messages were numbered like the error messages then they could have distinction: e.g. 'ok1' == 'previous command finished executing' etc.
Perhaps something to think about.

[doppelhub]

Yes, this is certainly possible. However, we need to send as few characters as possible, so that grbl can focus on keeping the motion planner full... just like echoing all commands is likely to cause grbl to stutter, we run into issues where long g-code files end up requiring grbl to send several characters to ack each line. For example, sending "ok153645" for g-code line 53645 requires grbl to spend four times more time servicing the serial send buffer. Therefore, I recommend creating a ring buffer (0x0 to 0xF), and then replacing 'ok' with that character (e.g. 'k1, k5, kA, kF, etc). We then leave it to the host to remember which line corresponds to each 'ok' command. This only works because grbl's buffer can only store fewer than sixteen lines.

We're eventually going to implement this behavior into our grbl branch... of course, note that this will break compatibility with almost every grbl host controller (e.g. grblPanel, etc)... they're expecting 'ok', and won't know what to do with 'k5'.

[doppelhub]

To check if the planner buffer is empty, send '?' and then see when the buffer is empty.

[Moffy]

That sounds good. Nice compromise.