开源改变世界

M0后无法恢复 #773

推推 grbl 2年前 (2023-02-01) 197次浏览
关闭
Harvie 打开了这个问题 2018 年 3 月 7 日 · 8条评论
关闭

M0后无法恢复#773

Harvie 打开了这个问题 2018 年 3 月 7 日 · 8条评论

注释

M0后无法恢复 #773
合作者

当我的 g 代码文件包含 M00(例如,用于工具更改)时,grbl 暂停,但不能从 bCNC 取消暂停。
在通用 g 代码发送器中,我只需单击“播放”按钮即可继续,而 bCNC 的“播放”按钮在代码到达 M0 时变灰,因此我只能通过“停止”按钮中止 g 代码执行到达 M0。

M0后无法恢复 #773
贡献者

嗨,Harvie,
对我来说,“暂停”按钮的作用是继续。我通常在换刀程序 (M6) 中使用它。
你试过了吗?

M0后无法恢复 #773
合作者作者

@goddisignz根据工具提示,它应该恢复,但它不起作用:

M0后无法恢复 #773

M0后无法恢复 #773
合作者作者

@neilgill写道:

我尝试双击暂停,然后再次双击暂停,在每次双击之间等待,两三下后,我的机器恢复了。它似乎始终如一地工作,双击几次即可运行。

@vlachoudis @chamnit有什么想法为什么 grbl 在第一次尝试时不恢复吗?

M0后无法恢复 #773
合作者作者
哈维 评论了 2018 年 8 月 11 日  

我刚试过什么@neilgill说是真的。当第一次激活进给保持时,我需要双击暂停按钮来取消暂停。然后它按预期开始工作,直到我重新启动 bCNC。

M0后无法恢复 #773
合作者作者
哈维 评论了 2018 年 8 月 11 日  

好的。这不是 grbl 错误。我已经点击了 arduino 上的重置按钮,它仍然可以通过单击来工作。我还使用拦截来嗅探串行流量,我发现 bCNC 正在发送“!” 而不是“〜”。双击可能会在再次重写之前快速翻转sender._pause的状态。这解决了这个问题。

M0后无法恢复 #773
合作者作者
哈维 评论了 2018 年 8 月 11 日  

如果我更改,我刚刚在第 1018 行的 Sender.py 中找到:

                                                if not self._alarm:
                                                           CNC.vars["state"] = fields[0]

                                                CNC.vars["state"] = fields[0]

它工作正常。

@vlachoudis是否有理由在警报模式下忽略机器状态?是什么导致 bCNC _alarm?根据 GRBL,我不应该处于警报状态。我猜 bCNC 处于警报状态,即使 GRBL 没有。

我知道如果出现错误 (_alarm == True),机器状态不会更新,以便持续显示错误消息。问题是状态不仅用于显示目的,还用于 bCNC 的内部工作。我认为应该有一个单独的框来累积显示错误,这些错误不会被实时状态更新覆盖,所以这些可以保持真正的实时……

在我看来,默认情况下 _alarm 为 True,但在成功连接到 GRBL 后没有将其设置为 false。

Harvie 向 Harvie/bCNC 添加了引用此问题的提交 2018 年 8 月 11 日

这个被引用了2018 年 8 月 11 日
M0后无法恢复 #773

我曾经在按下暂停按钮后看到这个问题。(我不记得以前尝试过 M0。)

我目前无法使用最新的 grbl 版本和来自 git repomaster分支的最新 bCNC 重现 M0 或暂停按钮的问题。

查看当前在 中的代码,目前已master为此修复此问题,这解释了为什么现在可以正常工作:
129ba69

1017                                                 #FIXME: not sure why this was here, but it was breaking stuff                                                                                            
1018                                                 #(eg.: pause button #773 and status display)
1019                                                 #if not self._alarm:            
1020                                                 CNC.vars["state"] = fields[0]   

我没有看到此更改带来的任何不利影响,但我很乐意看到Sender该类的一些适当的单元测试,以验证我们不会以某些不良状态结束。

默认情况下,当串行端口打开时(在 中)显示为self._alarm已设置 (True), 并且需要稍后明确清除。 查看代码以查看清除的位置,我看到了此更改:每当从 grbl 收到“ok”时,5f16bbf 都会被清除,但提交5f16bbf更改该行为。 因为这意味着在设置时继续处理 gcode 是可以接受的,所以我认为修复提交129ba69可能是安全的。Sender.open()

self._alarm

self._alarm
self._alarm

我不相信现在self._alarm真的做了任何有用的事情。
该代码仅检查它在其他 2 个地方的状态,这两个地方都暗示 grbl 正在向我们发送有效信息。
即使self._alarm需要,也肯定不再好命名了。

我正在使用 Arduino Nano(未连接 CNC 硬件)进行测试。
Grbl版本:

$I
[VER:1.1g.20180614:]
[OPT:V,15,128]

bCNC版本:

$ ./bCNC --help | head -n1
bCNC V0.9.14 [5 Feb 2018]

感谢收听,
扣篮。

M0后无法恢复 #773
合作者作者

似乎是固定的