注释
.png "高速弧上的轴失速 #212"){kind=avatar}
|
我很抱歉。这似乎与问题#143中看到的问题相同。 |
.png "高速弧上的轴失速 #212"){kind=avatar}
|
@physisisics：电弧问题与慢跑问题略有不同。Arcs 需要大量 CPU 来计算航路点，有时速度太慢无法跟上。v0.9 通过延长航路点解决了这个问题，但在您指定的特定误差范围内。我认为它的默认值为 0.0001″。比大多数 CNC 机器的能力要低得多。使用 v0.9，您可以像机器一样快地运行弧线。使用 v0.8c，您不能也必须限制进给率。 慢跑问题与缺乏覆盖保护的规划器有关。这种情况很少发生在程序中，但在慢跑时确实会发生，因为您正在输入多个单一命令。在一个程序中，您有两组缓冲区来防止这种情况发生。我们正在为这个特定问题制定 v0.9 的解决方案。它与进给率覆盖密切相关，因此我们可能需要一段时间才能想出同时适用于两者的方法。 |
|
谢谢回复。它实际上是缓冲区不足和 AVR 328 最大化的结合。我制作的圆形口袋在中心有一个椭圆岛。在查看 g 代码后，我发现我使用的 CAM 程序 (HeeksCNC) 决定一系列小圆弧是制作这个口袋的最佳解决方案。在较长的处理时间和较小的缓冲区之间，这一系列的小电弧会持续且重复地使电机停在同一位置。 附带一提，我遇到了与 v0.9 a 相同的问题，因为仍然存在此缓冲区问题。当我找到时间时，我将按照另一条评论中的建议编译一个具有更快串行接口的版本（我现在没有时间寻找线程）。 另外，我可能在 v0.9 中发现了一个错误。我没有运行归位循环，因为我的机器还没有限位开关。因此，机器坐标中的零位于我的机器行程中间的某个位置。当我测试 v0.9 时，我发现如果我发出一个 G0 移动通过机器的零位，它会简单地停在零位。然而，在机器停在零位之后，我可以发出另一个命令让它移动过去。这是一个已知的错误，还是我应该为此发布一个单独的问题？ |
|
的确，如果您正在运行非常高速的弧线，尤其是连续的和小的弧线，您仍然可能达到 328p 的极限。为此表示歉意。我们无法对弧线做很多事情来让它更快。一种选择是将圆弧转换为明确的线段。Grbl 可以比圆弧更好地处理单个线段的数学运算。我认为有一些程序可以为您做到这一点。 另外，你能把你的设置打印出来吗？我个人已经成功地以超过 1000 毫米/分钟的速度运行 1″ 直径的圆弧，所以我很好奇你的设置有何不同。也许包括你正在使用的一小段 g 代码，即这些圆弧有多小. v0.9 绝对不应该这样做。这是一个错误。可能应该放在一个新的问题中。仅 v0.9 会发生这种情况吗？并且只有 G0？当我有机会时，我会看看是否能找到造成这种情况的原因。 |
|
首先让我声明，至少我认为，这种停顿可能是机器特定的。由于这是一台便宜的机器，我用便宜的电机/电子设备制造了它。无需深入了解太多细节，电机电感低（即它们具有平坦的扭矩曲线）但相当弱（我实际上不知道额定值，因为我买了它们多余的）。因此，它们可以快速旋转，但不能承受高加速度。如果我是正确的，在具有更高扭矩电机的机器上进行测试可能会产生不同的结果，尤其是在处理上述缺乏规划器覆盖保护的情况时，其中可能存在几乎瞬时的大加速度。 这是我的相关机器细节： 预编译（0.8c 和 0.9 边） 其他一切都保留为默认值。 请注意，我不会接近 30 kHz 的脉冲率。另外，正如我之前所说，我的机器可以在这些设置下毫无问题地处理直线切割。 这是运行到问题部分并通过问题部分的 g 代码片段（之前将 F 设置为 1000 mm/min）： G01 X-17.589 Y104.393 我可以为这个故事提供更多细节，但这篇文章太长了。就 V 0.9 优势而言，我的大脑不能很好地处理多任务，而且由于我目前正在处理其他事情，所以我没有切换太多参数。我刚刚注意到 G0 过零问题并继续前进。 |
|
谢谢（你的）信息。看起来你的设置没有任何异常，我的铣床也有非常相似的设置。此外，您制作的圆圈非常大，因此 v0.9 绝对不会给您带来任何弧形生成问题。对于这些尺寸，线段将在毫米数量级，Grbl 可以毫无问题地处理它。 因此，正如您所说，这确实让我认为这是一个特定于机器的问题。我开始认为您的其中一根轴可能不喜欢比其他轴移动得更快，那根轴正在停滞。在v0.9中，你可以设置每个轴的速度限制。如果其中任何一个超过其限制，Grbl 将自动缩放进给率。我会尝试调整此设置并查看其响应方式。 另外，你们有龙门式铣床吗？如果是这样，那么必须移动整个磁头组件（包括 x 轴、z 轴和主轴）的轴是否就是您遇到问题的轴？这通常是这类机器的罪魁祸首，也是我们在 v0.9 中安装加速度和速度限制的原因。 |
|
是的，我有一个龙门式铣床。实际上，我将进给速度设置为 1000 毫米/分钟，由于我的 z 轴而受到特别限制。我对无错误的 V0.9 感到非常兴奋，因为这样我就可以可靠地增加我的提要。正如我所提到的，与我的机器实际可以做的相比，我已经大大降低了进给速度和加速度值，即使在切割材料时也是如此。 当我说机器特定问题时，我指的是由于规划器中的缓冲区覆盖而导致的颠簸运动（即大加速度）。我的电机只是失速，而更强大的电机也许能够处理它。 作为旁注，运行 V0.8 c（我还没有在 V0.9 上尝试过），我设置了一些测试 g 代码，通过以 1000 毫米/分钟的速度将它们细分为四个 90 度圆弧来切割 100 毫米半径的圆饲料。如果我让 GRBL 在 0.1 毫米分度/弧段的默认弧段分度上运行，电机最终会失速。但是，如果我将其更改为 5 毫米分度/弧段，我可以可靠地循环 gcode 100 次而不会出现错误。这对我来说听起来像是一个处理滞后错误，不是吗？如果你有兴趣，这里是 g 代码： G0 Z5 顺便说一下，感谢您抽出宝贵的时间来回答我的问题。我知道时间是多么宝贵，我真的很感激。 |
|
是的，在 v0.8c 上，您可能会遇到高进给率弧的停滞问题。在 v0.9 上，您不应该像您报告的那样。它应该自动缩放圆弧段，使其远远超过失败的 0.1 毫米分度。这就是为什么这让我相信这是你的机器。 电机在运行中根本不应该抖动或失速。每当你这样做时，你就会失去机器的位置，一切都会变得一团糟。目标是完全没有停顿。所以，当你确实有停顿时，它应该只发生在慢跑（不包括太快的弧线）和仍在执行时发送新动作（在某些情况下）。要阻止它，您真正需要做的就是在发送更多命令之前确保移动完成。否则，我们可能会在其他地方遇到更大的问题。 至于 v0.9 有问题，自发布以来没有任何报告的错误，除了归零周期需要对其进给率进行一些工作以及您所说的 G0 通过原点问题。否则，我会说使用它是安全的。我将检查您报告的错误的代码。 |
|
我不确定为什么，也许我不小心以某种方式切换了软限制，但我重新加载了 V0.9 a（与上次相同的文件）并且我无法重现不通过机器零的 G0 命令。如果我再次遇到它，我会让你知道， |
|
由于时间不够，我不得不继续解决这个问题，但我确实找到了一个创可贴。“修复”是在 V0.9 中使用更大的弦长设置。我使用 0.2 毫米/弧而不是默认值 (0.005 毫米/弧)。我认为此设置可能会在我的 7″ 半径弧中留下一些明显的直线，但我在橡木中工作，所以我总是可以将任何瑕疵打磨光滑。在我继续之前，我还有两个关于问题性质的潜在线索即使我仍然没有将问题的原因缩小到我的机器或 GRBL。 它似乎不是运行缓冲区问题，因为我在重新编译的V0.9版本中将串口波特率提高到57600并得到了完全相同的结果。 此外，我回到 GRBL V0.8c 并使用上面几篇文章提到的设置运行了我之前在线程中发布的第一段代码。当我只运行代码片段时，我的机器没有停止；即使我将代码循环 10 次。但是，如果我从头开始运行整个代码（上面未显示），我的机器每次都会在同一点停止（大约在上面提到的 g 代码部分的中间）。我可以在 GRBL V0.9 上重复这些相同的过程（针对 57600 的串行波特率重新编译）并得到相同的结果。这似乎指向 GRBL 的问题，但是，我的步进器失速仍然可能存在一些问题，因为弧码导致它通过中频带共振缓慢加速。我不太愿意这样或那样称呼它。 如果有人有兴趣尝试重现我的问题，请告诉我，我可以将整个 g 代码发送给您。当我有更多时间时，我将尝试在几周后回到这个问题上。Chamnit，感谢您在这里提供的所有帮助以及您为这款出色的软件所做的所有工作。 |
|
这确实非常令人担忧。感谢您花时间报告您的发现。v0.9 不应该绝对不需要 0.2 毫米的弧度公差设置才能工作，至少在概念上是这样。您可能发现了一个错误。 由于您已将这段代码作为一个片段和一个完整的程序进行了尝试，这也可能是一个问题，因为整个程序的界面由于某种原因超时。步进谐振是可能的。如果您确实有时间，您可以尝试通过使用不同的流程序（即我们提供的 stream.py 或 UGS）来消除这些变量，并分别改变微步但保持相同的轴速度。微步进将使步进器频率远离共振，足以向您展示磨机中物理反应的差异。 无论如何，请发布指向您的 g 代码的链接和您的设置的完整打印。我想看看我是否可以重现这个。并让我们知道任何进展！我也会这样做。 |
|
抱歉花了这么长时间才发帖。这是 g 代码的链接：https 我一直在使用 gcodesender 和 UGS，但接下来我会尝试使用 stream.py。另外，我会给出关于尝试改变微步进的建议。 |
|
谢谢（你的）信息。我也会努力弄清这件事的真相。 回顾一下您的一些评论。我想我错过了关于 g 代码弧非常小的部分。它们绝对很小。我正在查看 IJ 语句，而不是 XYZ 目标位置。如果这些太短（即没有很多线段）并且有像这样的连续弧，如您之前所述，设置计算的 CPU 开销可能大到足以使缓冲区饿死。如果是这种情况，我无能为力。它的效率差不多。 至于这个特定问题的解决方案，您可以直接将这些圆弧转换为明确的 G01 命令。一些体面的 CAM 软件包已经为您提供了执行此操作的选项。如果你的没有，可能会有一些人会为你做这个，即我的“PreGrbl”脚本回购做这个，但它已经过时了。 不管怎样，如果你发现了什么，请告诉我。 |
过去几周我一直在玩 GRBL 0.8c，我已经设法让我廉价建造的数控系统做一些非常巧妙的事情。我刚刚开始了一个项目，在橡木上切割一些相当大的圆形凹槽，这需要中等大小的切屑负载，所以我使用了 1000 毫米/分钟的进给速率和 30 毫米/秒^2 的加速度。对于橡木的直切，这些设置非常适合我的机器；但是，一个轴在切割圆弧时会一直停转。我逐渐将加速度降低到 3 mm/s^2，当很清楚失速的根源是什么时，电机仍在失速。
我正在用上面提到的高进给率和小加速度“点动”一个轴。这些条件允许在轴减速时有足够的时间发出第二个 G0 命令。如果第二个 G0 命令与轴先前移动的方向相同，并且在电机减速时通过，则电机会一直停转。听得见，步进电机响起，好像没有尝试加速它们，而是立即跳到设定的进给速度。
正如我所说，我将我的 cnc 与最便宜的零件放在一起，但我相当确定这是 GRBL 的一个错误。有更好的 cnc 的其他人可以重现这个吗？当您的电子产品、硬件和软件都处于测试阶段时，很难找出此类问题的原因。