注释
.png "M3 命令停顿进给率 V1.1f 08-01-2017 #264"){kind=avatar}
|
请发布您的 $$ 设置和 $I 构建信息字符串。你在做激光工作吗？ |
.png "M3 命令停顿进给率 V1.1f 08-01-2017 #264"){kind=avatar}
|
我的 $$ 和 $I 是： Grbl 1.1f [‘$’寻求帮助] 我已经检查过了，在另一个软件 Inkscape 0.92 中转换了捷豹标志，带有 laserengraver 扩展名，并且该扩展名吐出了 G2 和 G3，这个版本的 GRBL 没有问题。 是的，我正在进行激光作业。 使用 G1 M3 Sxxx 命令，它会提高进给率并减少到 0 |
|
正如 Grbl 激光维基页面所述，M3 的运行方式与 M4 不同。目前还不清楚你认为有什么问题。 使用 G1 M3 Sxxx 命令，您没有附加到命令的运动。Grbl 必须完成到目前为止所有排队的运动，才能在程序中的这个精确点设置激光功率。这种行为在激光维基页面中有明确说明，其中讨论了通过连续运动进行激光操作。 您的步进空闲延迟设置也很低。每次停止时，我都会使步进器暂时禁用。将其设置为 255。 |
|
正如 Grbl 激光维基页面所述，M3 的运行方式与 M4 不同。目前还不清楚你认为有什么问题。 为什么所有以前的版本都需要做他们需要做的事情而只有这个版本的行为不同？ wiki 是在最后一个 08-01-2017 版本之前编写的。我知道 M3 的行为与 M4 不同，M4 的行为是动态的，因此激光功率会在交叉点和弯曲处进行调整。M3 开/关响应。使用 S（主轴）命令的电源。 ` M3 S200 与以前版本的 GRBL 不同。在上一个版本中，它将进给率降低到 0，至少在反馈上它说是 0，因为进给率仍在继续，它只是在焚烧工件并且需要数小时才能完成一个小工作。 顺便说一句，当我尝试其他所有方法时，我只会放弃问题请求。所以我现在知道这是 M3 G1 组合命令的问题，M4 没有问题…… |
|
也许您指的是 2017 年 2 月的错误修复。此后的所有版本都有相同的更新。M3 之所以改变，是因为它解决了 M3 在某些情况下本应同步的问题。通过在运动不使用时强制 M3 停止，它确保激光始终正确设置，并且准确地位于程序中指定的位置。否则，M3 命令可能会在用户不期望的情况下打开或关闭。使用激光时，这是一种特别危险的情况。 请注意，我不会仅仅因为我可以就改变事情。特别是对于主版本。仅当存在可能危及用户安全的严重问题或可在不更改 Grbl 操作的情况下提高可靠性的小错误修复时。 同样，我可能误解了您认为的问题。如果您暗示存在新错误，我需要观看说明该问题的视频。 |
我实际上不是指任何东西。我注意到了一些事情，试图尽我所能解决它并得出结论，只有最后一个版本像我描述的那样。所有以前的 v1.1f 版本都按照它们对 M3 和 M4 命令的预期进行操作。只有 V1.1f 的 08-01-2017 版本正在这样做。 M3 在不运动时不会停止，它只是将运动减少到一个危险的低量（和 0 一样好，但仍在运动），这样你就烧毁了工件。 刷新 GRBL v1.1f_08-01-2017，并加载我在第一篇初始帖子中附加的文件。捷豹.txt。这是 M3 进给减速器，而第二个捷豹文件 Jaguar_M4.txt 是完全相同的文件，但使用 M4 命令并且工作正常…… |
|
当你说所有以前的版本时，你是指以前的版本吗？自一月份以来已经有三个。全年还有 9 次提交主源代码。您需要更清楚哪些受到影响。 如果 M3 在不应该移动的时候缓慢移动，那就有问题了。这在您之前的帖子中不是很清楚。现在，我会重新打开这个问题，直到我有时间测试和重现你的问题，这可能暂时不会。 |
|
M3 在应该快速移动时移动缓慢。在 gcode 反馈上，它表示 FEEDRATE 0，这意味着停止，但它确实移动了。每秒 1 毫米或更少，没有测量。 这些版本工作正常： 使用这些 M3 命令与 resp G1 或 G0 Xxx Yxx Fxxx 一起执行预期的操作。 最后发布 M3 命令与 resp G1 或 G0 Xxx Yxx Fxxx 一起将进给率降低到接近 0。G2 和 G3 没问题，它们工作正常。 |
|
在上一个版本中，在 G1 和 G0 运动上移动 M3 时，我的步进电机也会发出可怕的噪音。因为步子太小，动作太慢，可能是因为我的激光器是皮带驱动的，而不是滚珠丝杠。 |
|
@dutchpatriot: 我刚刚注意到您正在尝试根据 g 代码命令执行超高分辨率的激光作业。每个 g 代码命令大约 0.01-0.02 毫米。最重要的是，您正试图以 1500 毫米/分钟到 3000 毫米/分钟的速度执行它。这远远超出了 Arduino 328p 的能力。您正在尝试将每秒 2500 到 5000 个 g 代码命令推送到一个有限大小的规划器缓冲区中，该缓冲区的控制器每秒最多只能处理 400-500 个 g 代码命令。第二个问题是规划器缓冲区在任何给定时间都只有大约 0.15mm-0.3mm 的距离（15 个块，每个块 0.01-0.02mm）。你不能指望它在那个距离内完全加速。我很惊讶它能奏效。 您的 M4 工作“有效”，但这不是我所说的好。看起来作业的执行速度刚好足以在规划器中保持一定的低速。远不及编程速度。M3 作业可能无法正常工作，因为它必须做一些额外的工作来检查运行条件以减慢速度以使其足以拖动。 G2/3 arc 作业之所以有效，是因为 Grbl 将弧分解为大得多的线段。在0.1-1.0mm的数量级。几乎比您的 Jaguar 作业大两个数量级。我建议您将每个 g 代码块的线条大小增加到 0.1-0.2mm。你应该看到它运行良好。 |
|
@chamnit，我只是想通了，确实就是这样！ 我想出来是因为用 G-code Ripper 操纵了另一个 gcode 作业。该程序将所有 G2 和 G3 弧操作为 G1 命令。我不小心勾选了这个框，在查看代码后我注意到该作业确实没有进给率停顿。 很高兴知道我们今天都学到了，你 GRBL 甚至可以承担它无法处理的工作，只是自己想出办法来处理它，我了解到 Arduino 方面的技术部分仅限于你刚刚很好地解释的内容。 确实 M4 工作成功了，但不是根据设置，但又一次，GRBL 只是接受它并自行解决！ 非常感谢您的时间、精力和解释。 |
你好，
我注意到在 GRBL 版本 V1.1f-08012017 中，M3 以某种方式表现得很奇怪。如果我运行 Jaguar.txt gcode 文件，设置为 F1500 的进给率下降到 0，停止。但我得出结论，使用相同的进给率或我在 dragon1_0001.txt gcode 文件（也是 M3 Sxxx 设置）上设置的任何进给率都不会停止。查看gcode后我只能断定它与G1和G0运动有关，因为dragon1_001.txt gcode文件主要是G2和G3弧形运动。
Jaguar_M4.txt gcode 文件运行正常，进给率按照预期运行。
dragon1_0001.txt
Jaguar.txt
Jaguar_M4.txt
如果我刷新以前的版本，那么一切都可以。