根据此处的最新文档：

推送消息很容易识别，因为它们不像响应消息那样以 ok 或 error 开头。它们通常放在 [] 括号、<> V 形中，以 $ 或特定的文本字符串开头。

何时：我向 GRBL 发送?命令（实时状态报告请求）

预计
然后：Grbl 应该响应状态报告（在 V 形之间） – 如文档所述

实际
然后：Grbl 响应状态报告并发回一条ok消息以及两行分隔线。

假设我正在为 GRBL 实现基本的流媒体协议，它在ok发送新命令之前等待响应。从理论上讲，该?请求是一个很大的例外，因为我可以一遍又一遍地以 200 毫秒的延迟发送它，而不管其他命令如何，或者至少这是文档在“状态报告”部分下所说的：

这 ？每当 Grbl 检测到一个时，总是从串行接收缓冲区中取出并删除。因此，这些可以随时发送。此外，为了让 GUI 更容易获取状态报告，它们总是被 <> V 形包围。

如果我向 GRBL 发送命令（例如：我正在逐行传输 *.nc 文件）我将不得不等待ok每一行之间的响应，但轮询解决方案也在后台运行并在另一个线程上以低频率向 GRBL 发送?请求。我无法真正匹配请求-响应对，因为完全相同的响应将通过 GRBL 发送给我。下一个ok可能是我的状态报告请求或 *.nc 文件最后一行的匹配对。

看起来我每次在等待ok响应时都应该暂停轮询，但是这个主题的文档不是很清楚，也有错误的陈述。