注释
.png "减速结束时的长斜坡 #35"){kind=avatar}
|
我会尽快调查的。只是为了加快速度，您可以发布一些暴露问题的 g 代码吗？我最近应用了一些更改来避免此类错误。 |
|
基本上，当我将加速度设置为 500 并将运动设置为 5000 时，我会在 4 个运动末端中的大约 1 个处得到长斜坡。如果我以矩形或之字形移动头部，这似乎无关紧要。似乎几乎所有超级平滑的加速设置都表现出这一点。当我回到我的机器前时，我可以查看它是否与角度有关或其他任何因素。 一个考虑因素：Lasersaur 使用直接皮带驱动，这基本上意味着与丝杠驱动相比，快速头部运动实际上是相当慢的步进运动（我相信大约慢 10 倍）。我的设置如下： $0 = 32.808（步数/mm x） |
|
我现在没有安排好这些天奥斯陆的一切真的很奇怪，所以请多多包涵。你能试试边缘分支，看看错误是否仍然存在吗？我已经修复了一些可能相关的问题。如果它在 edge 中修复了，我将帮助您跟踪相关更改。 |
|
忘了它。我看到您非常了解最新的边缘补丁。它只需要等几天，直到我将 CNC 设置好进行测试。我通常只使用串行控制台和逻辑分析仪，但这个错误需要真正的硬件。 |
|
我今天在店里度过，试图了解这个问题。它毕竟不是那么随机。我做了以下有趣的观察： 长斜坡似乎与反冲击代码有关。当我将 9 美元的设置设置得非常高时（基本上就是说，我不想限制转角冲击），我没有得到任何长斜坡。 但是，在我有长坡的所有拐角处，速度变化异常剧烈。我的头移动一般平稳，但在某些角落，加速/减速代码似乎失败了。这是一个例子： G0 X60 Y120 F20000 我怀疑拐角越接近 180 度，速度差异越大，加速/减速代码产生抖动的可能性就越大。 我的 Grbl 设置是： |
|
请耐心等待。我还没有时间在我的店里进行测试。 |
|
我想我知道这种行为的原因： 我在块中添加了一个 final_rate 字段，以便准确知道何时停止减速。由于不可避免的舍入问题，最小速度可能会提前一点达到，但因为减速被限制在 final_rate 在大多数情况下都很好 – 除非最终速率非常低，如果你有限制性加加速度限制，它通常会得到, 非常高的进给率。验证这个假设的一个技巧是在 stepper.c 的 trapezoid_tick 中减速时设置一个较低的速率限制。我现在正在用手机工作，可能还需要几天时间才能真正验证它。 一个永久性的解决办法是确保舍入误差总是导致最终速度过晚而不是过早达到。 |
.png "减速结束时的长斜坡 #35"){kind=avatar}
|
我有时间研究这个问题。我在减速结束时遇到了同样的问题，有时在加速斜坡结束时会出现奇怪的电机失速。它似乎非常依赖于加速度设置、acceleration_ticks_per_second、进给率和计划线的长度。 Simen，我做了一些测试并设置了较低的速率限制，但收效甚微。查看代码并进行一些测试后，我现在认为这是由于 estimate_acceleration_distance 函数与 grbl 如何执行加速斜坡之间的差异所致。estimate_acceleration_distance 基于恒定加速度运动方程的精确积分，但 grbl 通过 acceleration_ticks_per_second（一种数值积分）进行离散减速/加速。换句话说，由于数值积分计算误差，grbl 可能会过早减速到最小速度并提前几步达到 final_rate。rate_delta 的舍入问题也可能有所贡献，但我认为这取决于具体情况。我’ 至于权宜之计，我通过调整 config.h (+/- 5) 中的加速度设置和 acceleration_ticks_per_second 参数来转移数值误差，因此我的机器上不会出现停顿问题，因此取得了一些成功在一个程序的持续时间内。 |
|
昨晚我有机会验证我的理论。如果我在 config.h 文件中提高每秒的加速步数，长坡问题就会越来越小。在我的叉子上，我把它升到大约 120 升，长坡问题完全消失了。到处。以 360L 的速度运行让一切都变得非常顺畅。与此同时，降低最大加速也应该通过创建更长的减速/加速减速来减少这个问题，这让 grbl dg 对其进行更多的离散速率调整，从而通过精确的解决方案获得更准确的结果。 |
.png "减速结束时的长斜坡 #35"){kind=avatar}
|
我只是在这个问题上花了很多时间，想出了两个函数来处理这个问题。我这样做是为了恒定加加速度（而不是加速），所以结果可能比您解决当前问题所需的更多 – 但改变加加速度实际上应该使方程式更简单，计算成本更低。这些函数是： get_target_velocity() – 在给定起始速度 (Vi)、移动或斜坡段 (L) 的长度和最大加加速度 (Jm) 的情况下返回可实现的目标速度 (Vt)。另一个函数是 get_target_length()，它返回在给定初始速度 (Vi)、目标速度 (Vt) 和最大加加速度 (Jm) 的情况下可实现的长度。方程式是： Vt = (sqrt(L)_(L/sqrt(1/Jm))^(1/6)+(1/Jm)^(1/4)_Vi)/(1/Jm)^(1/4) 如果您认为这对计算加速情况有用，我可以发布有关推导的更多详细信息。 |
.png "减速结束时的长斜坡 #35"){kind=avatar}
|
我在减速结束时得到了相同的长斜率。我是用示波器看的。但它并不总是发生。当轨迹长度很长时，它就会发生。有人修过这个吗？ |
|
我现在正在努力。这个问题似乎有多种原因。步进速率转换中整数数学的舍入误差，较长加速度中太多离散块的数值漂移或较短加速度中不够的数值漂移，步进曲线跟随方法，以及加速度数值和精确积分差异的截断误差。我已经能够解决一些更重要的问题，但我可能需要一段时间才能确保我有一些可靠的东西供其他人使用。几天后它可能会发布在我的叉子上。 |
|
亲爱的桑尼， 很高兴收到你现在修复错误的消息。 但是最近我发现了减速问题。 我有一个制造台式制造机器的计划。 从去年开始，我就和西门交换了一些想法。 我希望你修复它并尽快发布它。 问候， 保罗·杰 2011 年 9 月 21 日星期三上午 8:58，Sonny Jeon <
|
|
保罗，我实际上已经将 grbl“移植”到 xmega。但它更像是一个分支而不是一个端口。它已演变为 TInyG 项目的不同代码库。您可以在 Synthetos/TinyG github 上获取它。您可能对 CNC 代码感兴趣，也可能不感兴趣，但无论如何，您可能需要很多 xmega 特定代码。启动、时钟设置、中断处理、通过 EEPROM/FLASH 勘误表等。还有一个由 Alex Forencich 编写的 Xmegas 引导加载程序，我们已经实现了它，但它不在 repo 中。这是一个链接：https ://www.synthetos.com/blog/avr-xboot-on-tinyg/ 。如果您对任何进一步的细节感兴趣，请告诉我。 |
|
非常感谢您提供的 TinyG 信息。我买了波士顿安卓 问候， 保罗·杰 2011 年 9 月 21 日星期三晚上 7:11，Alden Hart <
|
|
保罗， 我实际上更喜欢支持 xmegas 所需的 SPI 协议的 Atmel AVRISP mkII 编程器。该编程器售价 35 美元，可从 Mouser electronics 等处购买。我把 xboot 放在那里，这对于偶尔更新来说很好，但是如果你正在做大量的闪存，硬件程序员会更可靠 – 如果你正在开发，你就会这样做。我从 Atmel AVRstudio4 驱动 AVR，但也有其他非 Windows 选项。我对 AVRStudio5 beta 的可靠性还不满意。 奥尔登 2011 年 9 月 21 日晚上 9:20，pauljay 写道：
|
|
我已经测试了 Chamnit grbl 代码，发现它工作正常。到目前为止没有减速问题。 我的配置如下。 $0 = 200.000（步数/mm x） 结果步进频率为 20KHz。我使用的是 10 微步驱动器，滚珠丝杠螺距为 10mm。 |
|
感谢您发布结果！ 前阵子我发布了一个错误修正来纠正进入和退出 桑尼 2011 年 9 月 22 日晚上 8:35，pauljay
|
|
好的。我已经找到导致此问题的主要问题。它在 stepper.c 中，它与减速/加速完成的方式和时间有关。为了修复它，我应用了曲线近似的中点规则（或者将它的速度开始变化的时间稍微不同）并确保步进中断将始终准确地准时停止和开始加速和减速。在我的工厂进行了测试，效果非常好。 在 config.h 中增加 ACCELERATION_STEPS_PER_SECOND 的另一个权宜之计解决方案仍然适用，特别是对于运行非常高加速度和进给率的人。 预计代码将在本周末的某个时候发布在我的叉子上。 |
|
伟大的。当你发布它时，我会在 Zen 上试一试。 2011 年 9 月 23 日下午 6:25，Sonny Jeon 写道：
|
|
昨晚在我的机器上运行了很多测试用例，一切都很好！代码现在发布在我的叉子上。如果你们中的任何人遇到任何问题，请告诉我，因为如果由于某种原因它不能解决问题，我将确保进行更多工作。另外，让我知道它是否也适合您！ |
我遇到了加速代码的问题。所有的加速阶段都工作正常，但在减速时我得到了不自然的长结束。基本上，运动会减速，就在它应该停止或过渡到下一个运动之前，它会继续非常缓慢地运动。
它相当依赖于设置，但通常似乎在运动设置非常平滑时发生。使用生涩的设置，一切似乎都很好。