数字输出控制（M64/M65） #513

@RyanGordon: 感谢您更新代码。所以，我一直在阅读 linuxcnc.org 上的 M64/65 g 代码描述。您的实施与所描述的略有不同。M64/M65 恰好在运动控制器处理指令时执行。这不是很好地定义运动控制器是什么以及实际运动与运动控制器接收命令时相比提前了多少。

如代码中所写，该行为将导致规划器缓冲区为空，这意味着运动将停止，打开/关闭 I/O 引脚，然后继续执行 g 代码程序。它基本上与运动同步，但不是停止运动。而且它不完全是其他与运动 g 代码同步的 M62/63。它介于两者之间。更不用说 M62/M63 有点奇怪，仅在下一个运动模式命令开始时启用，仅此而已。

我不确定如何解决此问题以及它将如何改变您的用例。

另外，如果有机会，请删除 report.c 中的所有更改，尤其是 invalid ID: 和 unused words 错误后面的空格。现在更改这些可能会破坏某些 GUI。

你好@chamnit

你说这段代码在精度意义上与标准不完全匹配是对的。看来如果我们要遵循 T 的标准，一旦 g 代码被解析、验证然后执行，M64/M65 命令就必须异步执行。这就提出了两个问题：1) 是否有可能更改代码以使 dio_immediate_run 函数调用异步？和 2) 鉴于它现在是同步的，对于我们的目的来说，运行 M64/M65 时花费的时钟周期是否可以忽略不计（因此在不中断运动的情况下有效地即时）？

我还取消了对 report.c 的其余更改

PS 我也不明白我的代码中究竟有什么会导致计划缓冲区为空？是protocol_buffer_synchronize函数吗？

1. Grbl 接收并解析 M64/65 命令时异步更改引脚状态应该没有问题。但是，这种引脚更改可能会比实时发生的事情提前 1 到 17 个区块。无法保证这将如何以及何时发生。这对您的用例来说可能会有问题。您可以通过在 M64/65 命令之前调用 G4 驻留来清空规划器缓冲区并同步所有内容来控制这一点，但用户不会立即明白为什么这适用于 Grbl 而可能不适用于其他地方。

2. 问题不在于花费的时钟周期，而是 Grbl 如何管理同步事件，如驻留和主轴/冷却液控制。它清空规划器缓冲区，导致机器停止，然后执行同步事件，并继续解析和重新填充缓冲区。现在，没有一种简单的方法可以在不停止运动的情况下执行同步事件。例如，如果您有两个 G1 命令夹着一个 M64，Grbl 将不得不在第一个 G1 命令结束时停止，设置 M64，然后加速返回以完成第二个 G1 命令。你想要的是在第一个 G1 命令结束时，M64 在那个精确的时刻被设置，第二个 G1 命令继续而不中断运动。

PS）是的，问题的根源是 protocol_buffer_sync 调用。在 v1.0 中，我计划安装一个单独的方法来进行实时同步，而无需停止。例如，实时激光更新或主轴 PWM 更新需要这样的东西。

我在边缘分支中的合并请求中处理的激光主轴应该显示如何处理这样的实时内容……
@chamnit: 你有机会看看合并吗？我猜您想自己以更通用的方式实现它？

@alpharesearch: 不，我还没有机会。由于新的探测周期命令进入，它导致您的拉取请求无法自动合并。当这种情况发生时，解决所有问题是一件痛苦的事情。无论如何，您的拉动代码会发生重大变化，花时间测试它主要是时间问题。

至于实施，我可能最终会自己做一些事情，但我认为这将保留给 Grbl ARM/v1.0，在那里我不必经常担心超过 Uno 的闪存和内存限制。

@chamnit啊，我现在明白了。所以也许最好等待一些围绕实时同步的改进重构。出于好奇，Grbl ARM/v1.0 版本是围绕 Arduino Due 构建的吗？

@RyanGordon: 目前还悬而未决。有很多 ARM 变体非常适合 Grbl ARM。其中一些非常便宜 (Teensy) 与定价过高 (Due)。该计划是将 Grbl 的大部分代码重构为可移植库，为该过渡做准备。大多数重构现在都在 Mega2560（未发布）上完成，只是因为它已经存在，我不需要重新连接任何东西，而且它有闪存和内存来稍微分散代码。FWIW，Grbl 真的不需要 ARM 芯片。它的效率如此之高，以至于 AVR 仍然可以推动它处理几乎所有事情。

@chamnit我从你的边缘到我的边缘进行了手动合并，它又恢复了工作（至少模拟器确实吐出了一个看起来有效的图形）……无论如何我们确实讨论过在所有功能上传递一个结构 – 这就是需要在这里工作。

关闭此数字 IO 拉取请求。它已被列入未来工作的待办事项清单。