一旦作业完全在规划器缓冲区中，覆盖就没有效果 #118

德雷斯科

虽然仍有一些行要从发送方接收，但覆盖（主轴/进给/快速）在作业执行期间的行为与预期一致。然而，一旦作业完全在规划器缓冲区中，那么覆盖似乎不再有任何效果？

我从软件发件人和我的控制面板插件中都观察到了这一点（在此之前我只是假设这是一个发件人错误）。有任何想法吗？

terjeio

发件人问题？

当我用我的发件人进行测试时，据我所知它可以正常工作。将有一个短暂的延迟（~100 毫秒？），因为无法修改段缓冲区中已有的运动。

德雷斯科

做了更多的测试。对我来说，在工作开始时——当接收缓冲区和计划程序缓冲区中都有数据时，然后按预期覆盖工作。一旦所有数据都在规划器缓冲区中，那么覆盖在作业完成之前不会生效（但它们会在某处排队，并在作业结束时全部应用）。

我确实认为这可能是一个发件人错误，但我也从我的控制面板插件中看到了同样的事情 – 它使用 grbl.enqueue_realtime_command() – 与 feed hold / cycle start 等相同，它们都按预期继续工作。

我可以在替补席上复制，所以会深入挖掘……

terjeio

这是与我的发件人一起使用的测试程序：

G0X0Y0Z0
G1Y50F50
X10
Y20
X30
M30

德雷斯科

有趣的是，那个也对我有用。这是一个没有的；

(Exported by FreeCAD)
(Post Processor: grbl_post)
(Output Time:2022-02-27 09:57:39.896810)
(Begin preamble)
G17 G90
G21
(Begin operation: Fixture)
(Path: Fixture)
G54
(Finish operation: Fixture)
(Begin operation: TC: 25.4mm Surfacing)
(Path: TC: 25.4mm Surfacing)
(TC: 25.4mm Surfacing)
(Begin toolchange)
( M6 T30.0 )
M3 S7200.0
(Finish operation: TC: 25.4mm Surfacing)
(Begin operation: LeadInOutDressup)
(Path: LeadInOutDressup)
(MillFace)
G0 X-19.150 Y18.950 Z5.000
G0 Z3.000
G1 X-19.150 Y18.950 Z-1.000 F420.000
G3 X-0.100 Y-0.100 I19.050 J0.000 F600.000
G1 X-0.100 Y-0.100 Z-1.000 F420.000
G1 X100.100 Y-0.100 Z-1.000 F600.000
G1 X100.100 Y16.918 Z-1.000 F600.000
G1 X-0.100 Y16.918 Z-1.000 F600.000
G1 X-0.100 Y33.936 Z-1.000 F600.000
G1 X100.100 Y33.936 Z-1.000 F600.000
G0 Z5.000
(Finish operation: LeadInOutDressup)
(Begin postamble)
M5
G17 G90
M2

德雷斯科

它似乎是由主轴停止（M5）引起的。一旦它被删除，或者程序结束移动到它上面，问题就消失了。

terjeio

核心/gcode.c

第 986 行 4ff8f1c

系统。旗帜。delay_overrides = 开；

就是这样，好收获。我必须重新编写这段代码——它用于在主轴同步运动处于活动状态时延迟覆盖。暂时取消注释该行。我将要用 STM32F411 驱动程序验证主轴同步，所以会看一下。

埃里克-莫尔巴赫

它似乎是由主轴停止（M5）引起的。一旦它被删除，或者程序结束移动到它上面，问题就消失了。

我做了一些测试，这也发生在 M8 和 M9 上。
检查 M7、M8 和 M9 时使用同一行。将其用于冷却液是有原因的吗？

一旦作业完全在规划器缓冲区中，覆盖就没有效果#118

评论