评论
|
我使用您的 G 代码程序遇到了类似的问题。我在 4x 到 5x 行附近看到了几个随机错误,但是,如果我用 替换该行
|
|
@cheton我相信它已经在我的分支上解决了这个问题。明天我将创建一个拉取请求并提交给您审查。基本上我的许多 gcode 都遇到了同样的问题,因为其中一些是“长”周长和低进给率…… 基本上它是关于 grbl 中命令缓冲区的块大小(在分析 gnea/grbl 之后)——我做了 2 个(两个小的改变): a) 防止溢出的位数从 8 字节到 16 字节——因为这是计划程序块的大小,串行缓冲区是使用这个特定大小收集的。 b) 重复时间——稍长一些,因为 grbl 在可用内存时响应可用内存……从 5 秒到 30 秒。 此更改不会影响其他操作。一切运行顺利,gcode 的错误停止了。 再次感谢这个软件,明天我将尝试用这段非常小的代码与您一起做出贡献。:) |
|
运行 G 代码程序时没有必要强制重新发送解析器状态 ($G),查询计时器的目的是确保 Grbl 会周期性地响应“?” 和引导期间的“$G”命令,对于一些罕见的情况(例如重新连接 USB 电缆等),它可能需要在引导加载程序准备好后再次发送 $G 到 Grbl。 8字节的扣除与Grbl的接收缓冲区大小(默认为128字节)有关,特别是在使用字符计数流协议时,我在发送端减小大小以确保它不会溢出Grbl的接收缓冲区。 CNCjs 服务器会定期向 Grbl 发送
为了保留更多空间以防止出现竞争条件(如果有的话),我将大小加倍为 8 个字节,因此发送方将假定它有 120 个字节(即 128 – 8)可供使用。 此问题已在此提交0148f35 #diff-4ecb4a936d43625e056e3cca7620e47eR484 中修复 它将在本周发布带有错误修复的 1.9.8。 |
|
我不确定实时命令是否“?” 会占用Grbl的接收缓冲区。如果它不占用接收缓冲区,我可以把它从计算中去掉。 |






我在使用 CNCJS 1.91、1.94 和 1.97 时遇到一些 gcode 错误,可能是其他版本,因为我只测试了这些版本。
1.8.17 没有任何错误,就像我使用 Carbide Motion 4 时一样。
使用带有 GRBL 1.1f 的 Shapeoko 3。
错误的确切行随着不同的版本和运行而变化,但这是一个日志:
T1
G17
G20
G0Z0.3000
G0X0.0000Y0.0000
G0X7.8375Y-5.5128Z0.1000
G1Z-0.0200F25.0
G1X-7.8375F50.0
G1Y-5.3253
G1X7.8375 G1Y
-5.1378 G1X.103-7
G1X-1.8475GG1X
–
7.8375F50.0
-4.7628
G1X-7.8375
G1Y-4.5753
G1X7.8375
G1Y-4.3878
G1X-7.8375
G1Y-4.2003
G1X7.8375
G1Y-4.0128
G1X-7.8375
G1Y-3.8253
G1X7.8375
G1Y-3.6378
G1X-7.8375
G1Y-3.4503
G1X7.8375
G1Y-3.2628
G1X-7.8375
G1Y-3.0753
G1X7.8375
G1Y-2.8878
G1X-7.8375
G1Y-2.7003 错误:3(无效语句)
G1X7.8375
G1Y-2.5128 错误:3(无效语句)
G1X-7.8375 错误:24(无效 gcode ID:24)
G1Y-2.3253
G1X7.8375 错误:3(无效声明)
G1Y-2.1378
G1X-7.8375 错误:3(无效声明)
G1Y-1.9503
G1X7.8375
G1Y-1.7628
G1X-7.8375
G1Y-1.5753
G1X7.8375
G1Y-1.3878
G1X-7.8375
G1Y- 1.2001.5
G1X12Y
–
837 7.8375
G1Y-0.8253
G1X7.8375
G1Y-0.6378
G1X-7.8375
G1Y-0.4503
G1X7.8375
G1Y-0.2628
G1X-7.8375 错误:3(无效语句)
G1Y-0.0753
G1X7.8375
G1Y0.1122 错误:3(无效语句)
G1X-7.8375
G1Y0.2997 错误:3(无效语句)
G1X7.8375
G1Y0.4872
接下来是另外大约 70 行,这些都很好。