评论
贡献者
发件人问题? 当我用我的发件人进行测试时,据我所知它可以正常工作。将有一个短暂的延迟(~100 毫秒?),因为无法修改段缓冲区中已有的运动。 |
贡献者作者
做了更多的测试。对我来说,在工作开始时——当接收缓冲区和计划程序缓冲区中都有数据时,然后按预期覆盖工作。一旦所有数据都在规划器缓冲区中,那么覆盖在作业完成之前不会生效(但它们会在某处排队,并在作业结束时全部应用)。 我确实认为这可能是一个发件人错误,但我也从我的控制面板插件中看到了同样的事情 – 它使用 grbl.enqueue_realtime_command() – 与 feed hold / cycle start 等相同,它们都按预期继续工作。 我可以在替补席上复制,所以会深入挖掘…… |
贡献者
这是与我的发件人一起使用的测试程序:
|
贡献者作者
有趣的是,那个也对我有用。这是一个没有的;
|
贡献者作者
它似乎是由主轴停止(M5)引起的。一旦它被删除,或者程序结束移动到它上面,问题就消失了。 |
贡献者
第 986 行 4ff8f1c
就是这样,好收获。我必须重新编写这段代码——它用于在主轴同步运动处于活动状态时延迟覆盖。暂时取消注释该行。我将要用 STM32F411 驱动程序验证主轴同步,所以会看一下。 |
贡献者
我做了一些测试,这也发生在 M8 和 M9 上。 |
虽然仍有一些行要从发送方接收,但覆盖(主轴/进给/快速)在作业执行期间的行为与预期一致。然而,一旦作业完全在规划器缓冲区中,那么覆盖似乎不再有任何效果?
我从软件发件人和我的控制面板插件中都观察到了这一点(在此之前我只是假设这是一个发件人错误)。有任何想法吗?