关闭 samitray 开了这个issue 2013 年 4 月 19 日 · 3条评论 关闭 识别正在处理的当前行 b GRBL#222 samitray 开了这个issue 2013 年 4 月 19 日 · 3条评论 注释 沙弥 评论了 2013 年 4 月 19 日 我的设置是一个使用 GRBL 和通用 GCode 发送器的小型 DIY 磨机,我想要 能够识别当前正在处理我的 NC 文件的哪一行 报告路径(部分发生在状态报告“?”)需要端点作为轮询? 可能会跳过确切的终点。 对于第 1 点, 是否有一种工具可以检索一些指向正在执行的当前行的 ID?然后 UI 可以使用此 ID 并突出显示相应的行 如果不是,那么我打算修改 GRBL 代码并返回带有 OK:XX 的 id,其中 XX 是一些计数器值,它“附加”到要处理的每一行 NC通过 grbl。 然后可以在 report_realtime_status <Run Mpos …. WPos … LidXX> 中发送此 ID 对于 point2 ,快速而肮脏的解决方案是在当前行完成时推出实时报告,因此我们始终会收到每次移动的终点 有人已经这样做了吗?我查看了 gcode.c 并在 gc_execute_line 丢失了它 成员 香奈儿 评论了 2013 年 4 月 20 日 @samitray: 我们之前考虑过这个,但决定不这样做。 首先,跟踪正在处理的行号需要 为每个计划程序块存储一个整数值。这听起来并不多,但我们 必须牺牲一两个规划器块(从 18 减少到 16)来 容纳它。不是我们想做的事情。我认为 GUI 应该 能够从对 发送到 Grbl 的块的“ok”响应的数量中间接地找出它们在哪里。UGS 已经在某种程度上做到了这一点,但 还不完全。我见过其他 GUI(不记得是哪些)也 使用实时位置反馈来确定它们的确切位置。 至于前进,当前执行的行可能不会进入 Grbl 的 328p 版本。根本就没有足够的内存、CPU 周期和闪存 来让它物有所值。我们即将启动的 ARM 版本将。 作者 沙弥 评论了 2013 年 4 月 20 日 感谢您的快速回复,我正在寻找一个简单的出路 看起来我必须加入一些肘部润滑脂并计算出基于 MPos/WPos 处理的当前生产线。 UGS 缺乏对正在处理的行的实时反馈,更新基于 grbl 解析器的响应, 它几乎总是更靠前。无论如何,我应该能够为 UGS 解决这个问题 作者 沙弥 评论了 2013 年 4 月 21 日 请关闭这个问题。 chamnit已完成 关闭 2013 年 4 月 22 日 喜欢 (0) M3/M4/M5标准? #180 方向盘 #223 v1.3.8-EDGE 重启后键盘快捷键消失 #427 关闭 无法在 gsender 1.2.0 中打开 .gcode 文件 #367 RaspberryPi 运行 gsender 时出现问题 #89 向 fluidnc 发送 $$ 会导致 gsender 崩溃 #473 v1.3.8-EDGE 重启后键盘快捷键消失 #427 关闭无法在 gsender 1.2.0 中打开 .gcode 文件 #367RaspberryPi 运行 gsender 时出现问题 #89向 fluidnc 发送 $$ 会导致 gsender 崩溃 #473功能请求:抑制发送到机器的 gcode 中的 gcode 注释。 #444 关闭通过网络连接进行连接 #171操纵杆运动的剩余问题 #204 关闭新版本认为我的机器一直处于锁定状态 #474 关闭
我的设置是一个使用 GRBL 和通用 GCode 发送器的小型 DIY 磨机,我想要
可能会跳过确切的终点。
对于第 1 点,
是否有一种工具可以检索一些指向正在执行的当前行的 ID?然后 UI 可以使用此 ID 并突出显示相应的行
如果不是,那么我打算修改 GRBL 代码并返回带有 OK:XX 的 id,其中 XX 是一些计数器值,它“附加”到要处理的每一行 NC通过 grbl。
然后可以在 report_realtime_status <Run Mpos …. WPos … LidXX> 中发送此 ID
对于 point2
,快速而肮脏的解决方案是在当前行完成时推出实时报告,因此我们始终会收到每次移动的终点
有人已经这样做了吗?我查看了 gcode.c 并在 gc_execute_line 丢失了它