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