Parsing Ctl: part of real-time report (or Pn: in later versions) 不工作？我已将 Pn: 的解析添加到我的 GCode 发件人中以取得良好效果，但是它需要信号保持足够长的时间才能被报告捕获。

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

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

我如何获得实时报告？它已经在上游 grbl/grbl 中了吗？我怎样才能启用它。
我想它只显示密码和状态。问题是“周期开始”按钮的引脚号在不同平台上可能不同。我想在流光中实现这一点，并考虑到未来的端口。
还。我可以确定不会收到两次消息吗？

@Harvie

我如何获得实时报告？

寄一个 ？特点。有关详细信息，请参阅维基。或者你的意思是如何将它添加到报告中？

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

是的。

我怎样才能启用它。

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

我想它只显示密码和状态。问题是“周期开始”按钮的引脚号在不同平台上可能不同。我想在流光中实现这一点，并考虑到未来的端口。

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

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

不，您的发件人中的状态处理必须解决这个问题。只要信号处于活动状态，它就会被报告。

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

是的，但这不是实时的

或者你的意思是如何将它添加到报告中？

我有 $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 在空闲期间更改 pin 状态时立即发送报告吗？

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

@Harvie

我们可以让 grbl 在空闲期间更改 pin 状态时立即发送报告吗？

添加

bit_true_atomic(sys_rt_exec_state, EXEC_STATUS_REPORT); 

到控制 ISR。

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

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

轮询状态有什么问题？

按下按钮的时间可能比轮询间隔短，因此不会引起注意。这会让我们感受到上个世纪制造的电梯按钮令人讨厌的反应迟钝的感觉。

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

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