注释
这已经讨论过几次,旧的讨论很难理解,但听起来你自己找到了答案。开始发送点动命令后,需要完成发送并等待 OK 响应返回,然后才能安全地发送点动取消实时命令。否则可能会出现竞争条件,取消命令在收到后立即处理,然后不久之后 grbl 完成处理慢跑命令并再次开始慢跑。 |
我只记得还有一个慢跑怪癖需要注意。发送实时点动取消命令后,立即发送“G4P0”并等待它确定后再发送任何其他内容。我忘记了具体原因,但如果您不等待取消操作完成再发送新的移动命令,就会发生坏事。 |
OK,我肯定是在motion_control.c,mc_line函数的代码中发现了bug: |
我已经解决了这个问题。清除串行输入和块缓冲区是不够的。代码只是等待所有缓冲区被清除,并立即发出挂起的命令——这个命令在代码中而不是在任何缓冲区中。这是跨线程同步问题。 |
我想出了如何在不使用 0x85 代码的情况下正确地慢跑:
代码中最终的公式为: 这在我的机器上就像一个魅力。 |
我忘了问: |
在我的 UGS 版本收到 OK 之前,我可以确认正在发送取消文件传输。 这是发送的最后几个点动命令的两个示例 当我松开慢跑按钮时,这导致慢跑在停止后继续慢跑
这个正确停止的地方
因此,GRBL 似乎存在取消可能导致不可预测状态的问题。 超程通常仅在长距离和高进给率下按住点动按钮时才会发生。 在长距离慢跑中,这个问题大约有五分之一发生。 是否有新版本的 GRBL 或 UGS 可以修复此问题? |
我在发送 0x85 命令之前添加了 6 毫秒的延迟,它确实为我解决了问题,再也没有发生过, 如果欢乐不居中 (我使用 ESP32 驱动操纵杆,通过板的串行连接器向 arduino uno 发送命令,这允许我使用操纵杆并通过蓝牙发送作业,grbl 1.1h 在 arduino 上,操纵杆和数据的自定义代码桥接 PC/Arduino 在 ESP32 上)。 如果有人感兴趣,我附上我的 esp32 代码(IDE 是安装在 Visual Studio 代码上的 PlatformIO) PS:使用notepad++查看,如果你还没有安装任何IDE的话,在language选项卡上选择C。 PlatformIO 安装的有用链接:https ://www.youtube.com/watch?v=JmvMvIphMnY&ab_channel=DroneBotWorkshop 希望这可以帮助。 |
你好,
我看到了 Issue #95线程并且我知道它已经关闭,但是这个问题仍然是一个问题(也发生在 Mega 版本中)
我想我有新的见解。它发生在一次点动取消时,没有发送进一步的点动命令。
这是发生了什么:当发送点动取消时,cnc 减速到停止然后再次开始走得比之前发送的单个点动段更远。
点动是通过连续发送 0.25mm 的运动来完成的,每次发送回“ok”。发送取消命令后,所有消息都将停止。
我已经对其进行了相当多的调查,这是我发现的:如果我在收到最后一个点动命令“ok”之前发送取消,它会触发问题。如果我等待确定,然后才发送取消,一切都很好。
看起来如果取消是在收到 ok 之前完成的,那么机器确实会停止并且所有活动缓冲区都被清除。然而,仍然有一个 pending planner command in the belly(可能在等待一个空缓冲区)执行并导致这个问题。
要重现该问题,请发送许多 0.25mm 的点动命令,直到没有返回 ok(缓冲区已满),然后立即发送取消。
我仍在研究 Grbl 代码,希望我能找到问题所在。
非常感谢这个伟大的项目!
晒。