注释
.jpg "使用高速时，步进器在加速结束时错过步进 #145"){kind=avatar}
|
首先，我不是这方面的开发人员，因此您应该对我所说的一切持保留态度。然而。 关于使用 grbl 以 22KHz 步进 – 这很可能，我不知道，但请考虑这些事情：
现在，所有这些都没有直接暗示以该频率步进是行不通的，但我认为它可以让人对一般事物有一些看法。您可能偶然发现了一个真正的错误（遗憾的是我无法确认或反驳），但您也可能刚刚达到 grbl 可以在不踩到自己脚趾的情况下所能做的事情的极限。 关于您使用的设置（和编译时选项，如果适用）的明确详细信息可能也有助于讨论这一点。 |
.jpg "使用高速时，步进器在加速结束时错过步进 #145"){kind=avatar}
|
我还可以确认上升斜坡上的砰砰声，就像电机停止加速并进入恒速状态一样。到目前为止，它并没有导致我的机器丢失任何步数，主要是因为电机非常笨重，步进驱动器是一个强大的动力源，因此速度的这种快速变化完全在规格范围内。 另外（而且我知道这很难正确修复），不应该只在 DIR 实际更改时才插入 DIR->STEP 延迟吗？这意味着大部分时间都可以跳过延迟，从而提高整体最高速度。 最后（我知道这真的很难），我认为应该努力计算 grbl 可以发出脉冲序列的最高速度是多少，并通过钳制用户发送到计算的 F 值来在代码中强制执行绝对最大值。在 1/2 小时后准备好您的零件不会让任何人不高兴，因为轴丢失的步骤而将其报废会毁了您的一天。 |
|
@csdexter：当然，理想情况下，只有在适用时才执行 DIR->STEP 延迟会很好——不知道这是否已经如此。相反，它可以完全消除，如果我们将它应用于产生前一个步进脉冲的非活动边沿的中断（需要时）。 另外，如果可能的话，+1 用于限制处理。如果它取决于太多的事情而无法准确确定，另一种解决方案是简单地检测事情何时实际超出规范（跳过中断等），并以某种方式向操作员显着地发出信号 – 所以至少知道 grbl 不能处理当前的铣削设置。如果不出意外，它至少会在每次不运行时绊倒时让您安心。 |
|
这绝对是个bug，类似于减速结束时的尾巴。这里最有可能发生的事情是加速上升比计划的速度曲线晚了一点。因此，当它到达应该巡航的部分时，它可能会发出您一直听到的砰砰声。我正在努力修复 v0.9 中的这两个加速/减速问题，但这个问题还有更多内容。 作为@csdexter提到过，他听到砰的一声，但没有迷路。这是步进电机的问题。随着速度的增加，步进电机会迅速失去其保持扭矩，因此您的步进电机可能更容易受到步进生成中的小变化/不准确的影响，正如您所发现的那样。要增加步进电机的高速扭矩，最简单的方法是增加驱动器电压和/或使用完整或更小的微步。因此，这个问题可能非常依赖于设置，并且让 grbl 进行一些限制处理可能很难跟踪所有这些变量。 自从我加入 Grbl 以来，支持的 30kHz（Emc2 是 20kHz）就一直存在，但我还在示波器上使用曲线重 g 代码程序测试了这个频率，以验证它不会使 Grbl 崩溃。很难说加速或减速斜坡在做什么，而且我没有可以那么快的备用步进电机。由于这可能非常依赖于设置，我不能说我们是否应该将支持的速率降低到 20kHz，但我想我记得看到 Shapeoko 的人一直在这个 20-30kHz 的频率范围内运行，没有任何报告的问题. 他们使用皮带驱动系统，进给率低，但步进频率高。 在我看来，检查是否更改 DIR 引脚可能与设置它们一样昂贵，但可能有另一种方法可以做到这一点。我可以看到如何在运动的加载阶段设置方向销，但我记得，当我看过一次时，并没有一个干净的方法来做到这一点。无论如何，当我为进给率覆盖重写步进模块时，我会将它添加到（不断增加的）列表中。 |
|
@blinkenlight> 当前代码将在每一步之前插入选定的延迟，因为步进中断不区分 STEP 位和 DIR 位（并且不存储旧值，因此它不能这样做 就像我说的，所有这些都是不平凡的工程问题（我知道是因为我最近也遇到了它们），但我想它们值得研究。 |
|
@blinkenlight: 误读了你的帖子。我计划 2012 年 11 月 27 日上午 7:21，“Asztalos Attila Oszkár”< @csdexter https://github.com/csdexter：理想情况下，当然，只有在适用时才执行 DIR->STEP 延迟会很好 另外，如果可能的话，+1 用于限制处理。如果它取决于太多的 — |
.png "使用高速时，步进器在加速结束时错过步进 #145"){kind=avatar}
|
需要明确的是，当它发出砰砰声时，我不能确定我错过了一步，我假设砰砰声是由于缺少一步造成的，但也可能是你所说的其他原因。 至于扭矩，我将该步进电机的当前设置为最大值，并且我可以使用简单的步进电机驱动程序更快地运行它，所以我在步进电机的能力范围内进行了很好的测试（仅供参考，大多数步进电机都有 10 转/秒的限制，但很多我测试不要接近那个）。 我认为 Max speed 应该像 Marlin 中那样设置。任何超过用户定义的最大速度的指定都会简单地截断为最大速度。由于扭矩、驱动类型、驱动重量等，最大速度取决于 Bot。 如果未设置最大速度并且请求的速度导致步进频率超出 MCU 的能力，则应将频率简单地设置为 MCU 可以处理的最大频率。 在我的测试代码中，我计算步进频率，然后测量实际频率以确保我在 MCU 功能范围内。 |
|
是的，已经计划像您现在描述的那样实施最高速度限制。其他事情优先考虑，比如进给保持和工作坐标，因为大多数人在了解他们的机器后可以自己管理这些。 Grbl 的步进驱动器的工作方式与我见过的有些不同，其中很多似乎是基于 D. Austin 的实时步进生成算法。这是一个很好的算法，可以生成非常非常干净的加速脉冲。但是，根据我的经验，它有一个致命弱点，除非您自适应地更改某些参数，否则它只能在一定程度的限制范围内运行良好。它可能会变得混乱和临时。我有一种感觉，您使用的简单步进驱动器可能具有更干净的加速度，因此没有重击并且可以以更高的速度运行。 我不是在宣传 Grbl 的步进算法很棒。不是，因为它有自己的已知问题。我已经修补了其中的许多问题以尽量减少这些问题，但正如您所发现的那样，在某些情况下仍然会出现。但是，它适用于大多数常见用途。要永久修复此问题并使其在所有应用程序中稳健地工作，确实需要对代码进行全面检修才能使其正常工作。也许是 D. Austin 算法或其他算法的混合。我需要对似乎最有效的方法进行调查并将其整合进去。有谁知道现在哪种步进算法看起来是最好的？ 无论如何，就像我之前说的，它是要做的事情和调整/修复的首要任务。现在，请放慢您的步进速度，直到推送修复程序。 |
|
@chamnit> 唯一浮动的是 Pramade 的逆向方法，它计算每次的步数而不是每步的时间。它也恰好是 TurboCNC 所做的:-)它的优点是它只使用加法和减法，但运行在 16MHz 的 ATmega328p 是否确实可以进行 uint32_t 的加法和比较来决定是否在以最高速度可用的小窗口中，STEP 脉冲是否到期（并更新当前速度）。 |
|
@csdexter: 似乎找不到对 Pramade 逆向方法的任何引用。或者获取 TurboCNC 的源代码（无需付费）。你有我可以细读的例子或文件吗？ |
|
@csdexter @wolfmanjm：当你在步进电机中遇到这种砰的一声时，我可以让你们把你的 Grbl 设置和 g 代码命令打印出来给我吗？此外，如果您更改了 config.h 文件中的任何内容并创建了您自己的构建，请将这些更改也发送给我。我打算使用@jgeisler0303的 grbl sim 代码来观察正在发生的事情并尝试以这种方式进行调试。谢谢！ |
|
在接下来的两天里我离开机器时在周六早上设置转储，当我拿到我的笔记本电脑时，在几个小时内进行 Pramade 链接和代码。 |
|
我的大脑又一次失灵了，这个人的名字是“Pramod Ranade”。这是文章：http 再次找到 TurboCNC 链接后，我会立即发送它:-) |
|
我使用了 grbl master 的当前 GIT 克隆，并使用 make 命令进行了修改，唯一的配置更改是将 X steps/mm 设置为 55。其他一切都是默认值。（我只使用 X 轴来测试使用 pololu a4988 驱动程序的独立步进器）。 $0=55.208 (x, step/mm) 在 GRBL 0.7 上，变化很小，X steps/mm 设置为 55 加速度设置为 1000 G代码非常简单…… G1 X600 F15000 以上工作正常，如果我设置 F24000，我会在加速结束时听到砰的一声。任何高于 18000 的 F 都会让我感到震惊。 |
|
奇怪的是，加速度非常高。它应该更像是 25-50 mm/sec^2，而不是 1000。实际上，加速度不应该那么高，尤其是当您将它们连接到导螺杆和工作台时。master 分支的最后一个克隆是什么时候？简而言之，有一段时间我搞砸了加速默认值，它应该已经被修复了。 而且，如果您需要较高的加速度，比如大于 100，您还需要增加 config.h 中的 acceleration_ticks_per_second 参数以创建更平滑的加速曲线。这可能会使砰砰声消失。 |
|
@csdexter: 感谢您的链接！有趣的想法。你是对的，随着步骤的滴答作响，它确实有相当高的成本。如果我们要支持 30kHz，我们可能需要至少在那个频率（可能是两倍）上有一个步进标记来执行所描述的算法。但我认为我可以将这本书的部分内容、D. Austin 的和 Grbl 的部分组合成可以很好地工作的东西。（希望）在不久的将来进行大量测试和编码。 |
|
首先，请放心，以下任何内容都不是批评或指责任何人的意思，我只是报告我的发现，希望在某个时候找到更好的解决方案。 然而。 我们可能希望将 grbl 自述文件从“…超过 30kHz 的稳定、无抖动的控制脉冲”更新为“稳定、无抖动的控制脉冲——只要只有一个轴在移动”。出于这个原因，请随时查看图表 [1]，对于任何进给率和加速度，都可以通过简单的“G0 X10 Y6”轻松联想到。这当然绝不是一个错误，它只是 Bresenham 以它应该的可怕、糟糕的方式工作——是的，它在计算上很便宜，但它也会在启动时在那个特定的屏幕截图中导致一个半毫秒的抖动。如果你说 Mach3 或 EMC2 会在它们的最大步进频率下做同样的事情，你可能是对的，它们确实如此 – 但我们对任何频率，即使是在低速下——仅仅因为这就是 Bresenham 的工作原理。尽管如此，每次看到那张照片时，我都感到非常不安。必须有比这更好的方法…… 其次，我想我知道“砰”的一声是从哪里来的：如你所知，步数是通过将 Timer1 比较寄存器设置为特定值而生成的，导致定时器持续计数到该限制并自动复位并引起中断每次到达它。问题是，正如 AVR 数据表还提到的那样，如果在实际定时器值接近它的时间点尝试更新比较寄存器，通过将新值设置为当前定时器值，比较就会错过，并且计时器在达到新的下限之前进行完全溢出运行。我相信这正是正在发生的事情：看展览 [2]。 那里相当可怕的“差距”大约是。4.160 毫秒宽，顺便说一下，这非常接近定时器 1 在全倾斜（没有预分频器）下运行的 65536 滴答溢出运行 – 即 4.096 毫秒 – 加上一个步进周期，即在间隙之前大约 66 微秒。换句话说，在加速斜坡结束时，中断所花费的时间开始接近步进周期，以至于当它到达时序更新部分时，它已经比所需的新步长更长时期。gap 没有持续发生的唯一原因是下一次执行的中断代码的平速运行分支可能更短，因此设法在步骤周期结束之前执行并再次触发中断。不过，并非总是如此。其中谈到展品 [3]，这看起来很像一个错过的步骤，并且经常出现在随后的平坦运行部分。在减速时我们没有这个问题，因为我们一直在设置更长而不是更短的比较周期，所以我们永远不会“错过”计数器。这样做的主要问题是它暗示这不仅仅是一个错误，而是一个限制——即使我们永远不会将比较限制设置为低于当前计时器，中断的某些分支显然已经无法及时运行这些案件… [1] – http://tinypic.com/r/291dvsp/6 |
|
值得深思：德州仪器 (TI) 有一份名为 SLVA448 的应用说明，其中非常有趣地介绍了使用配备 OCR 的定时器来生成步进脉冲（避免了上述问题）。你可能想看看它。 |
|
我非常感谢这个建议，但我怀疑那是错误的代码。我的意思是……“了解光伏及其背后的市场力量”？ |
|
@blinkenlight: 没有责备。:) 步进算法有很多可以做得更好的地方，现在我正在努力重新设计它，现在是提出所有这些的好时机。 首先让我说，自从我开始开发 Grbl 以来步进模块没有改变的主要原因之一是它的开销非常低并且相当高效。它不需要很多额外的计算，为主程序留下更多的 CPU 周期。在尝试安装更多功能时，我不知道我们还剩下多少个周期可以使用，所以它一直保持原样。请记住，我们比基于 PC 的系统更受周期限制，因此我们必须解决这个问题。 To improve the Bresenham algorithm, the easiest thing to do is to increase the resolution of it. Smoothieware, based on Grbl, basically doubles the resolution so the main driving step count is performed every two interrupts and the other step counts can fire at any interrupt. This means that you don’t have nearly as large of gaps between steps for certain moves like your exhibit [1]. It works well, but has a bit of higher cost. The Pramod Ranade algorithm brought up by @csdexter does basically the same thing, but at much higher step tick resolution and would run all axes nearly independently. Meaning no Bresenham issues. The problem is that we’re generating step pulses and parsing g-code at the same time, where Pramod Ranade’s (and D. Austin’s) algorithm was originally designed for dedicated microprocessors, and this algorithm will most definitely take up all of the CPU cycles at 30kHz. At this point, I think it’s possible to look into installing something like Smoothieware’s approach, possibly as something adaptive so that step resolution scales with step frequencies. So, at low step frequencies, say < 10kHz, it would double the Bresneham resolution, and above 10kHz, it would run normally. Anyhow, I don’t expect Grbl to have anymore major changes that would effect any time-critical processes, at least other than feedrate overrides, which I’m trying to do concurrently. So we can try something like this. |
我只是在测试空载步进电机的速度上限时注意到这一点。
我已经用一个简单的程序测试了这个步进器，这个程序只是以已知的速度向它发射步进，相当于在一个 55 步/毫米的系统上的 F24000，它工作正常（但这是上限）。
当我在 GRBL 中发布 G1 X500 F24000 时，它会加速并发出砰的一声，然后它平稳运行并减速。G1 X0 F24000 也会发生同样的情况，因此它会在两个方向上发生。
改变加速度只会在砰砰声发生时发生变化，因为它似乎是在达到全速时发生的。
如果我发布 G1 X500 F20000 它工作正常，没有重击。
这不是扭矩问题，因为我通过每 50us 发出步数来测试步进器，当步数/毫米设置为 50 时大约 400 毫米/秒并且运行平稳。
在 F25000 上，它将以大约 22KHz 的频率发出步进，我相信这完全在 GRBL 的限制内。
这发生在 GRBL 0.7 和 master 的当前版本（0.8？）