解析Ctl：部分实时报告（或Pn：在更高版本中）不起作用？我已将 Pn: 解析添加到我的 GCode 发件人中，效果很好，但是它需要信号保持足够长的时间才能被报告捕获。

@terjeio我真的不喜欢这个主意。即使在状态报告间隔上独立按下短按钮，也应发送流请求。

@Harvie嗯，实时报告对我来说似乎没有问题，但是我几天前才添加了这样的功能……如果你想捕获（真的）短按键，那么我相信你需要在 ISR 中捕获它们并设置标记它，以便前台进程可以发送它们，或者可能会进行轮询 – 例如。在protocol_exec_rt_system？如果发送不能延迟到下一个实时报告，这将需要一条新消息，使用存储的位而不是直接从 GPIO 寄存器读取的位。

我如何获得实时报告？那已经在上游 grbl/grbl 中了吗？我该如何启用它。
我想它只显示引脚号和状态。问题是“循环启动”按钮的引脚号在不同平台上可能不同。我想在考虑未来端口的情况下在流媒体中实现这一点。
还。我可以确定不会收到两次消息吗？

@Harvie

我如何获得实时报告？

寄一个 ？特点。有关详细信息，请参阅wiki。还是您的意思是如何将其添加到报告中？

那已经在上游 grbl/grbl 中了吗？

是的。

我该如何启用它。

它由 v1.1 中的#define REPORT_FIELD_PIN_STATE 启用（默认），在早期版本中由#define REPORT_CONTROL_PIN_STATE 启用（非默认）。

我想它只显示引脚号和状态。问题是“循环启动”按钮的引脚号在不同平台上可能不同。我想在考虑未来端口的情况下在流媒体中实现这一点。

Pre v1.1：它是将控制寄存器内容作为一个数字，一个位域。从 v1.1 开始：在字符串中编码的各个位，每个字符代表函数，例如。’S’ 表示循环开始。如果您要支持 v1.1 之前的版本，您可能需要添加如何解析位域的配置。

还。我可以确定不会收到两次消息吗？

不，您的发件人中的状态处理必须处理好这一点。只要信号处于活动状态，它就会被报告。

寄一个 ？特点。有关详细信息，请参阅 wiki。

是的，但这不是实时的

还是您的意思是如何将其添加到报告中？

我有 $10=3 的 v1.1，它没有显示 Pn: 或 Ctl: on ？命令：

<Idle|MPos:0.000,0.000,0.000|Bf:15,128|FS:0,0>
<Idle|MPos:0.000,0.000,0.000|Bf:15,128|FS:0,0|WCO:20.000,0.000,0.000>
<Idle|MPos:0.000,0.000,0.000|Bf:15,128|FS:0,0|Ov:100,100,100>

啊哈。它仅在该按钮处于活动状态时显示：
<Idle|WPos:-20.000,0.000,0.000|FS:0,0|Pn:S>

@terjeio
好的。伟大的。我已经设法修改 bCNC 以在激活 START CYCLE 引脚时开始流式传输。我对此很满意！

空闲时引脚状态发生变化时，我们可以让grbl立即发送报告吗？

这是添加此功能的 bCNC 提交：Harvie/bCNC@ 4a77780

@Harvie

空闲时引脚状态发生变化时，我们可以让grbl立即发送报告吗？

添加

bit_true_atomic(sys_rt_exec_state, EXEC_STATUS_REPORT); 

到控制 ISR。

是否可以在上游将此 grbl 默认设置为默认值？

@Harvie我对此表示怀疑，因为可能有一些 GUI 不喜欢获得它没有要求的状态报告。轮询状态有什么问题？它不需要任何更改或破坏任何东西，并且无论如何 GUI 都必须这样做

轮询状态有什么问题？

事实上，按钮的按下可能比轮询间隔更短，因此不会被注意到。这会让我们产生上世纪制造的电梯按钮那种恼人的反应迟钝的感觉。

@langwadt我相信“可能”可以从您上面的陈述中删除，当我的 MPG 挂件接管控制时，我遇到了一些发件人崩溃的问题。我决定自己写的原因之一。

解决此问题的一种方法可能是将控制引脚状态（通过 ORing 先前的值）存储在 ISR 中的变量中，并将其用于报告。也许最好由受保护的（原子/读写）来完成。报告代码应在报告完成后将其归零。也许这也行不通，但值得一试？