注释
.png "grbl 0.9c - 批处理一些 gcode 命令后停止工作 #336"){kind=avatar}
|
我认为我在 V0.8c 上遇到了相同或相似的问题。我将运行一个程序（在 la Skapeoko 的简单 3 轴 CNC 工作台上），在我重新获得对机器的控制之前，它会在强制硬重置的过程中部分冻结。UGCS 注意到一个报警故障。我安装了限位开关但禁用了，因为尽管 LS 线路上有屏蔽电缆、电容器和铁氧体，它们仍然太紧张。（我只是在设置期间启用限制和归位，然后在运行部件之前禁用，这样错误的触发就不会让生活变得更加困难）。我会从字面上完美地切割一部分，然后再次运行程序并让它随机冻结。 我真的很困惑是什么原因造成的。除了触发限位开关之外，还有哪些其他情况会引发警报？想知道我是否在触发警报的电机信号线上受到间歇性干扰。 渴望追查这个问题的根源。 |
.png "grbl 0.9c - 批处理一些 gcode 命令后停止工作 #336"){kind=avatar}
|
@Mgilbride: 据我所知，Grbl v0.8c 非常稳定，您不应该遇到这些类型的错误。Grbl v0.9b-c 的开发版本仍然存在一些问题，因此这里出现了停止问题。绝大多数时候，此类问题是由外部来源引起的，至少是过去的用户问题引起的。首先，我会消除可能导致这种情况的任何外部电噪声源，因为如果您有嘈杂的限位开关，那么这是一个明确的指标，表明某些东西没有正确接地或其他东西。确保所有东西都通过星形接地共享同一接地，以防止接地环路。确保所有电缆，尤其是与 Grbl 通信的 USB 电缆，远离任何潜在的电气干扰源。（如果没有，请尝试使用屏蔽 USB 电缆。它们更粗。) 最后，将您的流媒体节目作为变量消除。在我们的 repo 或使用不同库的其他一些 GUI 中尝试我们的 Python 流脚本。 如果您仍有问题，请不要犹豫，发布您的发现。另外，如果你解决了它，请告诉我们你做了什么来解决它。谢谢！ |
|
谢谢。我会试试这些。特别是消除软件并 我正在使用星地，但会再次审查它。 我的电子设备与电源一起封装在一个外壳中。一个 我只能说的另一件事是，我认为，但不确定，这 将及时向大家发布。感谢您的精彩固件！ 2014 年 1 月 25 日星期六下午 1:45，Sonny Jeon notifications@github.com写道：
|
.png "grbl 0.9c - 批处理一些 gcode 命令后停止工作 #336"){kind=avatar}
|
你好 我有同样的问题。 http://zapmaker.org/projects/grbl-controller-3-0/ grbl 通常在批量上传后冻结在完全相同的位置。 GrblController 有一个选项，“Aggresive Preload”…当我将其设置为 OFF 时，它不会再冻结…但这有一个缺点，即命令之间有短暂的延迟（GrblController 在发送下一个命令之前等待 OK ). 我什至尝试手动发送命令。一次发送一个命令时，它们会完美执行。但是当它们被批量发送时……这就是它发生的时候。 目前我没有安装限位开关。 锁定后，我必须重置连接才能让 grbl 再次工作。 谢谢！ |
|
@robertnino: 你用的是哪个版本的grbl？您是否尝试过使用不同的流媒体程序？你还在你的流中发送任何 G54-59 命令吗？访问 EEPROM 的某些命令尤其会导致 v0.9c 出现某些问题。我现在也在努力解决这个问题。 |
.png "grbl 0.9c - 批处理一些 gcode 命令后停止工作 #336"){kind=avatar}
|
去年我在使用 0.8c、Zapmaker 和 UNO 上的积极预加载时遇到了同样的问题。我需要预加载，因为标准加载的命令序列太慢了。它通常会在序列结束前锁定。经过大量测试后，我发现它取决于我在代码结束前立即使用的浮点命令的数量和精度。这不是缓冲区溢出。就我而言，我经常使用 G4 Px.xx 来精确计时转台和相机快门。Zapmaker 说这是因为 GRBL 如何处理 G4 命令，这与模态操作有关。我有一个 100% 可重复的短代码序列。如果有人感兴趣，我可以挖掘它。 -安迪 发件人：Robert Voinea [ mailto:notifications@github.com ] 嗨 |
|
我忘了补充。Zapmaker 在他的下载器中添加了几行代码（在 3.something 中），基本上是说“IF G4 Px，等待“OK””。这解决了 grbl-controller 的问题，但让我的代码太慢了。 安迪 发件人：Andy Nobbs [ mailto:andy_nobbs@yahoo.com ] 去年我在使用 0.8c、Zapmaker 和 UNO 上的积极预加载时遇到了同样的问题。我需要预加载，因为标准加载的命令序列太慢了。它通常会在序列结束前锁定。经过大量测试后，我发现它取决于我在代码结束前立即使用的浮点命令的数量和精度。这不是缓冲区溢出。就我而言，我经常使用 G4 Px.xx 来精确计时转台和相机快门。Zapmaker 说这是因为 GRBL 如何处理 G4 命令，这与模态操作有关。我有一个 100% 可重复的短代码序列。如果有人感兴趣，我可以挖掘它。 -安迪 发件人：Robert Voinea [ mailto:notifications@github.com ] 嗨 |
|
@lakeside53: 请发布您的示例代码的链接。我很好奇是什么导致了这个问题。这听起来主要是流媒体客户端方面的流媒体协议问题，主要是由于可疑的“IF G4”声明。这可能意味着 Zapmaker 使用的流媒体协议可能不完全兼容。对于某些命令，如 G4 驻留或 M3/4/5 主轴控制，Grbl 必须清空其缓冲区以完成队列中的所有运动以按时按程序执行命令。G2/3 arcs 暂停流式传输以将小线段注入规划器缓冲区。如果流媒体程序并不总是考虑到“OK”响应，您将遇到您所描述的问题。正如我们的高级流媒体脚本中所述，通过跟踪发送的字符和“ok”响应的数量，同时保持 Grbl 的串行输入缓冲区已满，可以通过一些方法来改进和稳健的流媒体性能。不过，我仍将针对我们的流媒体脚本进行测试，以确保它不在 Grbl 的末端。 仅供参考，Grbl 的模态操作主要是由于内存限制，但如果正确地流式传输到 Grbl，它不应该真正影响性能或操作方式。使 Grbl 成为非模态的仍然是可能的，因为我一直在为此寻找简单干净的解决方案，但这不是优先事项。基本上，它涉及必须在内存中存储任何非运动 g 代码块命令，并在步进模块完成前一个块时执行它们。 |
|
我搞砸了——Zapmaker 修复了“if Mx”，而不是“if G4”。抱歉，那是去年四月的事，自从他们 J 之后发生了很多事情 我可以发送整个文件，但它们只是重复序列——旋转表执行短序列、旋转表等。 问题是程序序列如何终止。我可以为它提供足够的数据以全速长时间（几小时？）执行下面的操作，并且它不会失败直到退出。 以下两个示例之间的唯一区别是 G4 P0.11 工作，而 G4 P0.1 失败 – 但仅在程序退出时。需要明确的是——每个命令都按预期工作，但我无法重新获得对 GRBL 的控制我在后来的实验中发现我可以通过简单地添加一些“什么都不做”G 代码来解决这个问题（比如定位一个不存在的Z 轴）在最后一个序列之后，但在 M30 之前（参见上一个示例）。如果使用“激进的预加载”，这只是一个问题；命令的标准加载速度较慢，但它可以工作。我是将 M30 移除还是留在里面都没关系。 Zapmaker 放入的“if M7”修复程序只是帮助我解决问题的快速破解，但我必须删除它，否则我的速度优势就会消失。就我而言，积极的预加载是可行的方法。我必须查看他的最新代码，看看它是否仍然存在。如果您想知道……速度和设置延迟的能力很重要。在下面“积极预加载”的序列中，我可以在大约 30 秒内拍摄 90 张高分辨率照片（相机是限制因素）；没有预加载大约需要 1.5 分钟（grbl 限制）。将其乘以数千个序列，然后…… 为了清楚起见，我伪造了一个旋转轴 这每次都有效（grbl 0.8c） G92 X0（零 X = 当前位置） G0 X0（从这里开始） G0 X4（下一个位置（4 毫米/英寸 = 度） G0 X8 ….. G0 X352 G0 X356 M30（停止） 每次退出时都失败（grbl 0.8c）： G92 X0（零 X = 当前位置） G0 X0（从这里开始） G0 X4（下一个位置（4 毫米/英寸 = 度） G0 X8 ….. G0 X352 G0 X356 M30（停止） 这“修复”了退出上述“总是失败”序列的问题： …… G0 X356 （停止前暂时什么都不做） G92 Y0 M30（停止） 发件人：Sonny Jeon [ mailto:notifications@github.com ] @lakeside53 https://github.com/lakeside53 : 请发布您的示例代码的链接。我很好奇是什么导致了这个问题。这听起来主要是流媒体客户端方面的流媒体协议问题，主要是由于可疑的“IF G4”声明。这可能意味着 Zapmaker 使用的流媒体协议可能不完全兼容。对于某些命令，如 G4 驻留或 M3/4/5 主轴控制，Grbl 必须清空其缓冲区以完成队列中的所有运动以按时按程序执行命令。G2/3 arcs 暂停流式传输以将小线段注入规划器缓冲区。如果流媒体程序并不总是考虑到“OK”响应，您将遇到您所描述的问题。正如我们的高级流媒体脚本中所述，通过跟踪发送的字符和“ok”响应的数量，同时保持 Grbl 的串行输入缓冲区已满，可以通过一些方法来改进和稳健的流媒体性能。不过，我仍将针对我们的流式脚本进行测试，以确保它不在 Grbl 的末端。 |
|
我检查了 Zapmakers 的最新代码 – 仍然有 M9 的陷阱。我必须对此发表评论以获得我需要的性能，我感觉有点糟糕，因为我是他为其添加它的人（不确定他是否有其他人有问题）:-) 当然，我的应用程序使用 m8 /m9 有点不寻常。是的，它“解决”了这个问题，但我只是在接近尾声的地方添加了几行“对我什么都不做”的代码，也解决了这个问题。 这里的代码片段来自他的 https://github.com/zapmaker/GrblHoming GrblHoming / gcode.h 类 CmdResponse -安迪 发件人：Andy Nobbs [ mailto:andy_nobbs@yahoo.com ] 我搞砸了——Zapmaker 修复了“if Mx”，而不是“if G4”。抱歉，那是去年四月的事，自从他们 J 之后发生了很多事情 我可以发送整个文件，但它们只是重复序列——旋转表执行短序列、旋转表等。 问题是程序序列如何终止。我可以为它提供足够的数据以全速长时间（几小时？）执行下面的操作，并且它不会失败直到退出。 以下两个示例之间的唯一区别是 G4 P0.11 工作，而 G4 P0.1 失败 – 但仅在程序退出时。需要明确的是——每个命令都按预期工作，但我无法重新获得对 GRBL 的控制我在后来的实验中发现我可以通过简单地添加一些“什么都不做”G 代码来解决这个问题（比如定位一个不存在的Z 轴）在最后一个序列之后，但在 M30 之前（参见上一个示例）。如果使用“激进的预加载”，这只是一个问题；命令的标准加载速度较慢，但它可以工作。我是将 M30 移除还是留在里面都没关系。 Zapmaker 放入的“if M7”修复程序只是帮助我解决问题的快速破解，但我必须删除它，否则我的速度优势就会消失。就我而言，积极的预加载是可行的方法。我必须查看他的最新代码，看看它是否仍然存在。如果您想知道……速度和设置延迟的能力很重要。在下面“积极预加载”的序列中，我可以在大约 30 秒内拍摄 90 张高分辨率照片（相机是限制因素）；没有预加载大约需要 1.5 分钟（grbl 限制）。将其乘以数千个序列，然后…… 为了清楚起见，我伪造了一个旋转轴 这每次都有效（grbl 0.8c） G92 X0（零 X = 当前位置） G0 X0（从这里开始） G0 X4（下一个位置（4 毫米/英寸 = 度） G0 X8 ….. G0 X352 G0 X356 M30（停止） 每次退出时都失败（grbl 0.8c）： G92 X0（零 X = 当前位置） G0 X0（从这里开始） G0 X4（下一个位置（4 毫米/英寸 = 度） G0 X8 ….. G0 X352 |
您好，
grbl 的 0.9c 版本不能正常工作。如果我们从文件发送命令，甚至在 Universal GcodeSender 等应用程序上使用键盘，开发板就会停止工作，我们需要断开连接并重新连接才能正常工作。
还有其他人有同样的问题#334我刚刚创建了另一个来关注这个问题。