首先，我不是这方面的开发人员，所以你应该接受我所说的任何（自由的）盐。然而。

关于使用 grbl 以 22KHz 步进 – 我不知道这很可能，但请考虑以下事项：

• 在那个频率下，两步脉冲之间有 45us
• 以 16MHz 运行的 328 AVR 每我们执行少于 16 条指令，这意味着在 45us 中大约有 700 个顶部
• 对于每个步进脉冲，至少步进中断、步进结束中断（如果您使用该选项编译，可能还有 DIR 信号延迟中断）必须执行一次，甚至不用说像加速计划这样的其余代码等等
• 单独的步进中断（虽然显然不是一直执行所有它）目前包含大约 850 条（抱歉，更正了这个）指令（不包括它调用的其他函数 – 它确实调用了一些）。
• 步进脉冲的宽度设置高达 50us，这已经超过 45，这甚至没有考虑到每个脉冲的“非活动”阶段的额外持续时间。

现在，这一切都没有直接意味着以该频率踩踏是行不通的，但我认为它总体上为人们提供了一些看法。您可能偶然发现了一个真正的错误（很遗憾，我无法确认或反驳），但您也可能刚刚达到 grbl 在不踩到自己的脚趾的情况下所能做的极限。

有关您使用的设置（和编译时间选项，如果适用）的明确详细信息可能也有助于讨论这一点。

我还可以确认上升斜坡上的砰砰声，就像电机停止加速并进入恒速状态一样。到目前为止，它并没有在我的机器上造成任何丢失的步骤，主要是因为电机非常笨重，步进驱动器是一个强大的动力，因此速度的快速变化完全符合规格。

另外（我知道这很难正确修复），不应该只在 DIR 实际更改时插入 DIR->STEP 延迟吗？这意味着大部分时间可以跳过延迟，从而提高整体最高速度。

最后（我知道这真的很难），我认为应该努力计算 grbl 可以发出脉冲序列的最高速度是多少，并通过钳制用户发送到计算的任何 F 值在代码中强制执行它绝对最大值。让你的零件在 1/2 小时后准备好不会让任何人感到不安，因为轴丢失的步骤而将其报废会毁掉你的一天。

@csdexter：理想情况下，当然，只有在适用时才执行 DIR->STEP 延迟会很好 – 不知道这是否已经如此。相反，如果我们将它应用到产生前一个步进脉冲的非活动边沿的中断中（需要时），它可以完全消除。

此外，如果可能的话，为限制处理 +1。如果它依赖于太多事情来准确确定，另一种解决方案是简单地检测事情何时超出规范（跳过中断等），并以某种方式向操作员显着地发出信号 – 所以至少知道 grbl 不能处理当前的铣削设置。如果不出意外，每次它不会在跑步时绊倒，它至少会让人安心。

这绝对是一个bug，类似于减速结束时的尾巴。这里最有可能发生的事情是加速度的上升使计划的速度曲线晚了一点。因此，当它到达它应该在巡航的部分时，它可能会发出你一直听到的砰砰声。我正在努力修复 v0.9 中的这两个加速/减速问题，但这个问题还有更多内容。

作为@csdexter提到，他听到砰的一声，但没有经历过失足。这是步进电机问题。随着速度的增加，步进电机会迅速失去其保持扭矩，因此您的步进电机可能更容易受到步进生成中微小变化/不准确的影响，正如您所发现的。要增加步进器的高速扭矩，最简单的方法是增加驱动器电压和/或使用完整或更小的微步。因此，这个问题可能非常依赖于设置，并且让 grbl 进行一些限制处理可能很难跟踪所有这些变量。

支持的 30kHz（Emc2 为 20kHz）是我加入 Grbl 以来一直存在的，但我还在示波器上用曲线重的 g 代码程序测试了这个频率，以验证它不会使 Grbl 崩溃。很难说出加速或减速斜坡在做什么，而且我没有可以跑得那么快的备用步进电机。由于这可能依赖于设置，我不能说我们是否应该将支持的速率降低到 20kHz，但我想我记得看到 Shapeoko 人一直在这个 20-30kHz 的频率范围内运行，没有任何报告的问题. 他们使用低进给率但高步进频率的皮带驱动系统。

在我看来，执行检查是否更改 DIR 引脚可能与设置它们一样昂贵，但可能还有另一种方法可以做到这一点。我可以看到如何在运动的加载阶段设置方向销，但我记得，当我看过一次时，没有一种干净的方法可以做到这一点。无论如何，当我为进给率覆盖重写它时，我会将它添加到我将执行步进模块的（不断增加的）列表中。

@blinkenlight> 当前代码将在每一步之前插入选择的延迟，因为步进中断不区分 STEP 位和 DIR 位（并且不存储旧值，因此它不能这样做if(old != new) delay(); else skip();）。
此外，没有检查用户要求的 DIR->STEP 延迟是否实际可实现（最小值取决于特定数量 [OCRx 再次匹配之前要执行的指令数] 和不确定数量 [另一个中断触发，最有可能是UART]）。
最后，没有检查（和钳制）用户提供的 F 值是否可以执行这样的移动。该代码仅检查 F 是否高于设置中的最大机器速度，IIRC 还进行圆检查（给定当前 R 和请求的圆周相对 F，是否有任何轴高于配置的机器最高速度）。没有检查得到的步进周期（STEP 的两个连续上升沿之间的时间）是否足够长，以使步进中断的关键部分能够完全执行并且不会最终踩到它的脚趾。

就像我说的，所有这些都是不平凡的工程问题（我知道是因为我最近也遇到了它们），但我想它们值得研究。

@blinkenlight: 看错你的帖子了。我计划
为每个轴安装最大速度。所以这应该有效地做你的限制
建议。

2012 年 11 月 27 日上午 7:21，“Asztalos Attila Oszkár”<notices@github.com
>写道：

@csdexter https://github.com/csdexter：理想情况下，当然，只有在适用时才执行 DIR->STEP 延迟会很好
– 不知道这是否
已经如此。相反，如果我们将它应用到产生前一个步进 脉冲
的非活动边沿的中断中（需要时），它可以完全消除。

此外，如果可能的话，为限制处理 +1。如果它依赖于太多
事情来准确确定，另一种解决方案是简单地检测
事情何时超出规范（跳过中断等），并
以某种方式向操作员显着地发出信号 – 所以至少知道 grbl 不能
处理当前的铣削设置。如果不出意外，每次它不会在跑步时绊倒，它至少
会让人安心。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/ /issues/145 #issuecomment-10759454。

为了清楚起见，我不能确定当它重击时我错过了一步，我假设重击是由于丢失了一步，但它可能是你所说的其他东西。

至于扭矩，我将该步进器的电流设置为最大值，我可以使用简单的步进驱动器更快地运行它，所以我在步进器功能范围内进行了很好的测试（仅供参考，大多数步进器有 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 的源代码（无需付费）。你有任何我可以细读的例子或文件吗？

我记得看到的唯一一个很旧http://www.embedded.com/design/mcus-processors-and-socs/4006438/Generate-stepper-motor-speed-profiles-in-real-time

@csdexter @wolfmanjm：当您在步进电机中遇到这种重击时，我可以让你们给我发送您的 Grbl 设置和 g 代码命令的打印件吗？此外，如果您更改了 config.h 文件中的任何内容并创建了自己的构建，请将这些更改也发送给我。我打算使用@jgeisler0303的 grbl sim 代码来观察正在发生的事情并尝试以这种方式进行调试。谢谢！

在星期六早上设置转储，因为接下来的两天我要离开机器，几个小时后，当我到达我的笔记本电脑时，Pramade 链接和代码。

我的大脑又一次让我失望了，这个人的名字是“Pramod Ranade”。这是文章：http
: //www.eetimes.com/design/other/4026992/Linear-motor-control-without-the-math-item-1 如果文本不是，我也有付费 C 文件已经够清楚了。

再次找到它后，我会立即发送 TurboCNC 链接

我使用了 grbl master 的当前 GIT 克隆，并使用 make 命令完成了它，唯一的配置更改是将 X steps/mm 设置为 55。其他一切都是默认的。（我只使用 X 轴来测试使用 pololu a4988 驱动程序的独立步进器）。

$0=55.208 (x, step/mm)
$1=400.000 (y, step/mm)
$2=400.000 (z, step/mm)
$3=3 (step pulse, usec)
$4=300.000 (默认进给, mm/min)
$5=1500.000（默认搜索，mm/min）
$6=252（步进端口反转掩码，int:11111100）
$7=25（步进空闲延迟，msec）
$8=1000.000（加速度，mm/sec^2）
$9=0.050（结点偏差，mm)
$10=0.100 (arc, mm/segment)
$11=25 (n-arc correction, int)
$12=3 (n-decimals, int)
$13=0 (report inches, bool)
$14=1 (auto start, bool)
$15=0 (invert step enable, bool)
$16=0 (hard limits, bool)
$17=0 (homing cycle, bool)
$18=0 (homing dir invert mask, int:00000000)
$19=25.000（归位进给，mm/min）
$20=250.000（归位寻道，mm/min）
$21=100（归位去抖动，毫秒）
$22=1.000（归位拉断，mm）

在 GRBL 0.7 上变化很小，X steps/mm 设置为 55 加速度设置为 1000

G代码很简单…

G1 X600 F15000
G1 X0
G1 X600
G1 X0
G1 X600
G1 X0
G1 X600
G1 X0
G1 X600
G1 X0
G1 X600
等…

以上工作正常，如果我设置 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 会在它们的最大步进频率下做同样的事情，你可能是对的，他们这样做了——但我们对任何频率，即使在低速时 – 仅仅因为这就是布雷森纳姆的工作方式。不过，每次看到那张照片时，我都感到很不安。必须有比这更好的方法…

其次，我想我知道“砰砰”的声音来自哪里：如您所知，步骤是通过将 Timer1 比较寄存器设置为特定值来生成的，导致定时器不断计数到该限制并自动复位并导致中断每次它到达它。问题是，正如 AVR 数据表还提到的那样，如果尝试在实际计时器值接近它的时间点更新比较寄存器，则通过将新值设置为当前计时器值以下，比较会丢失，并且计时器在达到新的下限之前进行完全溢出运行。我相信这正是正在发生的事情：看展览 [2]。

那里相当可怕的“差距”大约是。4.160 毫秒宽，顺便说一下，它非常接近定时器 1 以全倾斜（没有预分频器）运行的 65536 滴答溢出运行——即 4.096 毫秒——加上一个步进周期，即在间隙之前大约 66 微秒。换句话说，在加速斜坡结束时，中断所花费的时间开始接近步进周期，以至于当它到达 update-the-timing 部分时，它已经比所需的新步进长了时期。间隙没有继续发生的唯一原因是下一次执行的中断代码的平速运行分支可能更短，因此设法在步骤周期结束并再次触发中断之前执行。不过，并非总是如此。说到展览[3]，这看起来很像错过的一步，并且经常出现在接下来的平坦运行部分。在减速时我们没有这个问题，因为我们一直在设置更长而不是更短的比较周期，所以我们永远不会“错过”计数器。主要问题在于它暗示这不仅仅是一个错误，而是一个限制——即使我们永远不会将比较限制设置为低于当前计时器，中断的某些分支显然已经无法及时运行这些案例…

[1] – http://tinypic.com/r/291dvsp/6
[2] – http://tinypic.com/r/33w756p/6
[3] – http://tinypic.com/r/21nmrkm/ 6

值得深思的是：德州仪器 (Texas Instruments) 有一个名为 SLVA448 的应用说明，其中非常有趣地介绍了使用配备 OCR 的定时器来生成步进脉冲（避免上述问题）。你可能想看看它。

我非常感谢这个建议，但我怀疑这是错误的代码。我的意思是……“了解光伏及其背后的市场力量”？

@blinkenlight: 不怪罪。:) 步进算法有很多可以做得更好的地方，现在我正在重新工作，现在是提出所有这些的好时机。

首先让我说，自从我开始开发 Grbl 以来，步进模块没有改变的主要原因之一是它的开销非常低且相当高效。它不需要很多额外的计算，并为主程序留下更多的 CPU 周期。在尝试安装更多功能时，我不知道我们还剩下多少个周期可以使用，所以它一直保持原样。请记住，我们比基于 PC 的系统更受周期限制，因此我们必须解决/解决这个问题。

要改进 Bresenham 算法，最简单的方法就是提高它的分辨率。基于 Grbl 的 Smoothieware 基本上将分辨率加倍，因此主驱动步数每两个中断执行一次，而其他步数可以在任何中断时触发。这意味着对于某些动作，例如您的展览 [1]，您在步骤之间没有那么大的间隙。它工作得很好，但成本有点高。Pramod Ranade 算法由@csdexter基本上做同样的事情，但步幅分辨率要高得多，并且几乎可以独立运行所有轴。意味着没有布雷森纳姆问题。问题是我们同时生成步进脉冲和解析 g 代码，而 Pramod Ranade（和 D. Austin 的）算法最初是为专用微处理器设计的，而且这个算法肯定会占用所有 CPU 周期在 30kHz。

在这一点上，我认为可以考虑安装类似 Smoothieware 的方法，可能是自适应的，以便步进分辨率随步进频率缩放。因此，在低阶跃频率下，例如 < 10kHz，它将使 Bresneham 分辨率翻倍，而在 10kHz 以上，它将正常运行。无论如何，我不希望 Grbl 有任何会影响任何时间关键过程的重大更改，至少除了我正在尝试同时进行的进给率覆盖之外。所以我们可以尝试这样的事情。

在展览 [2] 和 [3] 上，在追踪问题方面做得非常出色。我以为是加速算法的不准确，但看起来绝对不是。如果比较寄存器是 2 个字节，我想这是有道理的。对于 volatile 变量，在更新 >1 字节变量时必须注意，因为当两个进程同时更新它时，可能会更新一半。我也找不到 Radu 提到的 TI 论文，但听起来我们有解决这个问题的方法。如果我有时间，我会尝试对其进行修复，但其他人会这样做，我会全力以赴。

@blinkenlight我又坏了。自我提醒：不要在团队外的时候用电话写回复，这会导致错误！

SLVA488 是应用笔记的正确名称，这里是链接：http ://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slva488

@chamnit编译器负责以“正确的方式”（即 Atmel 所说的方式）更新 16 位寄存器。但是，如果您在启用中断的情况下这样做，这并不能使您免于意外，如下所述：http ://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_16bitio

当我玩 grbl 0.7 时，可能会留下高加速度，这接近于像 Marlin 这样的设置。我没有在丝杠系统上进行测试，因此通常在皮带驱动系统上使用高加速度。

将加速度设置为 50 确实会停止重击，但在从 x0 开始的 x600 上，它在开始减速之前永远不会达到最高速度，因此没有真正的方法知道重击是否存在或只是被隐藏。

将加速度设置为 500 它确实达到全速并且仍然砰砰作响。

我知道这可能是学术性的，因为我不会使用如此高的加速度进行铣削，但对于 3D 打印来说这很常见，尽管我也不会使用 GRBL 进行 3D 打印:)

编辑：我刚刚尝试在一个未连接的步进器上以 50 的速度加速，这样我就可以做 X5000 F20000，当步进器最终达到全速时，果然有一个砰砰声（虽然没有那么严重），尽管它需要一段时间才能达到速度！

@chamnit这里是 TurboCNC 链接：http ://www.dakeng.com/ltfaq.html#6.5 （6.5 是线性的，6.6 是圆形的）

希望这会有所帮助（如果 Pascal 太神秘，我很乐意提供翻译成 C）。

谢谢@csdexter对于链接。今晚读他们。

@wolfmanjm: 感谢您报告测试结果。这似乎是一个比第一次出现时更大的问题。我希望越来越接近解决它。

@blinkenlight: 图表 [3] 对我来说没有意义。在巡航阶段，主中断没有进行任何异常计算。只是在退出之前的一系列 if 语句。我也无法在我的示波器上重现这一点，即使以 30kHz 运行。所以，这里似乎发生了其他事情。您正在运行非库存构建吗？如果是这样，你改变了什么？如果不是，我重现这个的条件是什么？

文章@csdexter链接到引用另一篇文章的来源，我在这里给出了要点：https ://gist.github.com/4167029

@chamnit我很乐意为此提供帮助。如果你需要什么让我知道！

刚刚测试了步进驱动器的速度。我找到了罪魁祸首。这是速度更新中的一个小计算，大约需要 40-50 微秒，而计时器的实际设置只是其中的一小部分。巡航期间的主步进中断等其他所有操作仅需要 20-25 微秒，这是合理的。

原来是 stepper.c 中的这一行：

  st.cycles_per_step_event = config_step_timer((TICKS_PER_MICROSECOND*1000000*60)/steps_per_minute);

该计算会终止中断。理想情况下，这不应该超过几微秒，但我累了，需要去睡觉了。希望当我醒来时，有人可能已经找到了解决此问题的方法。否则，我明天晚上就试一试。

@tmpvar: 感谢您的链接和提供帮助！我认为现在最好的办法是开始调查哪种步进算法最适合用于 grbl。看来我们的开端不错。

@chamnit: 很高兴你找到了行为不端的部分。作为记录，我一直在做的测试是使用 0.8c 的可下载库存构建，速度为 400 步/毫米，加速度 = 100，步脉冲 = 10us，命令类似于 G01 X10 F3000（不确定最后一次进给我设置的速度是，但在那个附近）。我猜错过的步骤（“[3]”）是即使以稳定的速度偶尔执行的冗长计算的结果:)

此外，只是为了澄清问题 – 这不是 16 位寄存器以任何方式被错误更新的情况，并且处于中断中不是问题。它只是在当前计数器值“X”介于两者之间（B < X < A）的时间点将一个有效的“A”限制更改为另一个有效的“B”限制，从而使计时器免于遇到限制就像当内门关闭而外门打开时，气闸不会阻止恰好在里面的东西通过一样。数据表中的相关部分是 15.7.2，就在 15.5 之下

@csdexter：感谢您的链接，我想我现在有一些阅读（和很多思考）要做……

对不起，正确的问题，错误的计时器 – 我的意思是在图 16.6（第 128 页）下的第 16.9.2 节。

因此，看起来如果我们能够确保在最坏的情况下在 33 微秒（30kHz 步进速率）内设置步进中断和定时器，我们就不应该遇到这个问题。如果 Grbl 的主程序要做任何有意义的事情，我们可能需要将它控制在 20 微秒或更短的时间内。我也想知道这也会解决减速结束时的额外步骤，尽管我不知道这会如何影响它。一个人只能希望。:)

1. 理解并同意。当我们做大时，Grbl v1.0 可能会成为重点。

2. 伟大的想法。在集成硬件方面有一些工作，但我不知道它来自什么或来自哪里。有了更多的引脚和可用的内存，你说的任何事情都绝对有可能，特别是如果它设计得足够好，不会打扰步进驱动器。

3. 哈哈。我只是在笑，因为它太棒了。:) 以前从未使用过外部 RAM，但这是有道理的。

无论如何，关于将高频步进卸载到 Timer2 上，我脑海中浮现出更多的想法。我可能只是像这样全职以高频率运行，但是当以低步速运行时，它会增加 Bresenham 算法的分辨率。管理一切都有一些困难，但我认为这在不太多影响 Grbl 效率的情况下是可行的。

@csdexter关于 SPI。背景：我是 grblShield 的开发人员，并且一直在与 Sonny 讨论 post328p grbl。我一直在关注这些线程（全职工作！），但现在才加入。

在 Github 上查看 Kinen/Kinen。（也就是说，如果你能得到它，因为 Github 的那部分现在似乎已经关闭了）。我一直在和其他一些人一起研究这个问题，它解决了你一直在谈论的关于 SPI 和硬件扩展的很多问题。我有一些初步的 Kinen HW 正在运行，正在等待下一个董事会转速进来，这样我就可以继续了。我们已经很好地掌握了套接字规范 – 但当然它还没有最终确定。现在我们正在通过 SPI 协议工作，这可能会比 SPI 协议页面上的当前内容更 OO（JSONish）和更少的硬件。

——奥尔登

作为参考，这是我在上面谈到“串行 SRAM”时想到的那种芯片。

@aldenhart我检查了你的项目，看起来非常好，希望你能尽快达到生产状态。也祝你在完成总线规范的设计时能得到最好的启发，这类事情很难做到正确（正确 == PCI-style right）。

我想我在#145 (comment)中用blinkenlight 描述的根本原因找到了解决“砰砰”问题的方法。
这一切都在 atmega 规范中：http: //www.atmel.com/Images/doc8271.pdf

主步进中断当前在 CTC 模式下运行。这就是规范对 CTC 的规定：
“当使用十二种脉冲宽度调制 (PWM) 模式中的任何一种时，OCR1x 寄存器是双缓冲的。对于
比较 (CTC) 操作模式下的正常和清除定时器，双缓冲是禁用。双
缓冲将 OCR1x 比较寄存器的更新与计数序列的 TOP 或 BOTTOM
同步。同步可防止奇数长度、非对称 PWM 脉冲的出现，从而
使输出无毛刺。

该规范还继续描述了问题：
“……然后计数器必须计数到它的最大值
（0xFFFF）并在比较匹配发生之前从0x0000开始环绕。在许多情况下，这个特性是
不可取的。然后另一种方法是使用使用 OCR1A 的快速 PWM 模式来定义 TOP (WGM13:0 =
15)，因为 OCR1A 将被双缓冲。”

但也有解决办法。它被称为快速 PWM 模式：
“在快速 PWM 模式下，计数器会递增，直到计数器值与固定值
0x00FF、0x01FF 或 0x03FF（WGM13:0 = 5、6 或 7）中的任何一个匹配，即 ICR1 中的值（ WGM13:0 = 14)，或 OCR1A 中的值
(WGM13:0 = 15)。”
因此，对我们来说，WGM13:0 = 15 的快速 PWM 的行为应该与 CTC 模式完全相同，只是 OCR1A 是双缓冲的，这解决了将 OCR1A 设置为低于 TCNT1 的值的问题。

代码中的更改应该是直截了当的。当前边缘的第 353ff 行应为：

  // waveform generation = 1111 = fast PWM with OCR1A as TOP
  TCCR1B |= (1<<WGM13);
  TCCR1B |= (1<<WGM12);
  TCCR1A |= (1<<WGM11);
  TCCR1A |= (1<<WGM10);

有人有时间测试这个吗？我现在得和我的孩子们一起玩。我已经逾期了:-)

@csdexter：该芯片看起来是增加板载 RAM 和摆脱流媒体的绝佳解决方案。在我开始之前还有很多事情要做，但我愿意接受人们研究我们如何在 Grbl 中实现这样的东西。至少开始使用它，这样我们就知道安装某些东西需要什么。

另外，我一直在研究 Pramod 步进算法。它看起来是一个很好的解决方案（谢谢！），因为它基本上通过增加 Bresenham 算法分辨率来实现我的设想。因此，它应该使所有轴几乎彼此独立移动并且非常高效。现在，我正在戳戳代码，看看是否会有任何东西可以让 Grbl 绊倒它，但到目前为止一切都很好。如果一切顺利，可能不需要 Timer1，而 Timer2 会处理所有事情，因为该算法总是以高中断率运行。（虽然我不确定释放 Timer1 会带来什么新功能。）

@jgeisler0303：这可能会使问题好一些，但主要问题是 Timer1 中断在高步进速率下重新计算新步进时间所花费的时间太长。目前，ISR 至少需要大约 20 微秒来执行一个巡航步骤。使用时间重新计算，大约需要 60-65 微秒，主要是因为 40 微秒的除法计算。这意味着在大约 15kHz 或更高频率时，ISR 触发并退出，因为之前的 ISR 仍在忙于计算。因此，它会跳过该中断并等到下一个中​​断（但不会丢失任何步骤。它只是延迟了。）步进率越高，延迟的步骤越多，因此在 30kHz 处会发出声音。

我认为只要我们能够确保 ISR 可以在 20 微秒内完成和/或每个 ISR 以高步进率执行多个步骤，这个问题应该会消失。我正在研究一种新的步进算法，它应该一劳永逸地解决这个问题（希望如此）。新算法已经显示出很大的希望，并且据报道可以在 100kHz（这不是错字）下使用 FPGA 工作。对于 Grbl，这可能意味着保证 30kHz 甚至更快。

@csdexter关于Kinen项目。感谢您查看此内容。欢迎评论和观察。一切都是可编辑的 – 问题是开放的。我们正在努力实现互联网风格的“粗略共识和运行代码”。为此，很快就会有一块主板、一个愚蠢的步进驱动器翅片和一个温度控制器翅片从晶圆厂进来，以测试这些想法。

我真的很喜欢删除中断的想法。这将使 GRBL 更易于移植到其他版本的芯片。这就是阻止我让它在 Teensy 上工作的原因。我也可以尝试将无中断版本移植到速度更快（48MHz）并使用 ARM 的新 Teensy3。（而且真的很便宜）。有了这种额外的能力，我们也可以使用更复杂的算法。

只需阅读“Pramod Ranade”文章。那里没有说清楚，但是@chamnit已经提到过：所提出的算法是时域中的 Bersenham，快轴是快速定时器中断，慢轴是实际的步进脉冲。也就是说，很明显该算法会像空间域 Bresenham 一样表现出抖动。抖动在大约 0.66*max_timer_speed 时最差，然后脉冲间隔将在 1 和 2 个时间单位之间交替每隔一步。避免这种情况的唯一方法是让中断运行速度明显快于预期的最大步进速率。但是计算仍然必须在每个中断中完成。当然，它们只是添加和比较……但是……对于 FPGA 来说没问题。我并不是说不能用 16Mhz 8 位 RISC 完成，但我会太热情了。

顺便说一句：我在某处读到 Bresenham 在某种程度上是一种除法算法。这就是为什么使用“Pramod Ranade”算法可以避免速度倒置的原因。此外，快轴的长度，或在时域中的计时器速度，可以解释为计算的位数。

希望这对某些人来说很有趣。

@jgeisler0303：我确实对计算开销有些担心，但是与现在的 Grbl 相比，它并没有太大的不同。每次定时器改变时，我们仍然需要做很多加法和除法。Pramod Ranade 算法的主要优点是没有计时器变化，因此没有除法，这是杀手锏。

由于我们知道当前 ISR 在 20 微秒内完成几个 if-then 语句，并且在巡航期间每个中断至少 7 个 int32 加法/减法，我们可以想象在大约 15-20kHz 运行全时 ISR 来执行 Ranade 计算没有问题，这与正常操作中的开销大致相同。为了处理抖动问题，我正在考虑为 10-20kHz 的频率范围执行 2 个步骤，对于大于 20kHz 的频率范围为每个步骤执行 3 或 4 个步骤。频率应该如此之高和快速，由此引起的抖动应该是最小的。抖动在慢步速下应该最大，Ranade 算法处理得非常优雅。对于更快的 ARM 芯片，我们可以将 Grbl 的算法设计为从一开始就易于调整，

此外，加速/减速的处理更加精确，更新时只需要加/减。这意味着前瞻计划器将更加正确，并且希望移动结束时的步骤不再有任何问题。

无论如何，我认为 Ranade 算法在构建时可能无法正常工作，但我们仍然可以对其进行调整以非常轻松地完成我们需要的工作。如果一切顺利，我计划发布一个测试版本供人们在他们的机器上进行测试，因为不同的机器将有助于更快地调试这个东西。

@wolfmanjm: ARM 绝对是值得考虑的东西，虽然我真的对它们一无所知。Ranade 算法不会消除所有中断，但应该将它们减少到仅以高频率持续滴答的一个。如果在 ARM 上无法创建一致的系统时钟，请告诉我，以便我们调整思路。

我订购了一个 Teensy3，所以我可以对其进行测试。它确实有中断，并使用 Arduino 构建系统的修改版本，尽管我更喜欢 Makefile。

@chamnit我们这些 DIY 爱好者可以使用的所有 ARM 都有一个 SysTick。即使在某些特殊的芯片模型中情况并非如此，但绝对所有这些模型都具有可用于设置周期性中断的计时器。此外，大多数（如果不是全部）芯片都有一个 DMA 控制器，可以与定时器一起使用，以在当前匹配或定时器溢出时自动从 RAM 加载下一个 OCRx 值。这允许进一步缓冲和平滑，因为您可以提前计算整个斜坡，然后让芯片在无人看管的情况下通过它，而代码执行其他操作。
一些芯片甚至具有像 CCM（核心耦合内存，类似于 PC CPU 上的缓存，但你可以针对它，即告诉 CPU “我想要那些现在需要 4kB 的代码！”）或更小的“笨拙”辅助 CPU 内核，可以独立于主内核控制 GPIO 线（如 BeagleBoard/BeagleBone 上的 PRU）。

在我用 ARM 的魅力淹没线程之前，我会在这里停下来，特别是因为我自己还没有放弃 AVR。

仅供参考，毕竟不是一帆风顺。这不可能那么容易。:)

所以 Ranade 算法存在一个问题。与其他轴相关的错误。Grbl 使用的当前算法在数学上保证所有轴的步数都是预期的步数，即使是整数计算也是如此。如果没有充分考虑 Ranade 算法，则很容易出现舍入误差。这意味着非主要计数轴可以比预期的多或少一些。

有几种方法可以解决这个问题，但我还没有想出任何可行的强大方法。例如，缩放所有数字以使四舍五入最小/不存在，但由于 int32 是有限的，这最终可能会限制移动长度。或者强制计时器以步数的数学倍数计时，这将保证所有步骤都已完成，但依赖于始终设置计时器计时的费用。

无论如何，仍然在破解它。让大家知道我是否有进步。

@chamnit: 是的，正如墨菲所说，如果事情似乎变得更好，你就忽略了一些事情。特别是这个问题看起来不太亮 – 过去明显的解决方案似乎有明显的问题……很多似曾相识： http://forums.reprap.org/read.php? 147,87154

@jgeisler0303：那个快速中断的事情实际上听起来像是一个简洁的“缓冲”解决方案，以避免将来再次出现类似的问题（在主要原因 – 花费太长时间 – 当然首先被消除之后）。

编辑：对不起，我的意思是快速 PWM ……

@blinkenlight： 如此真实。虽然作为一名学者和受虐狂，正如奥尔登哈特所说的那样，我必须自己找出问题。我想这就是为什么他们称研究为“重新”搜索。

无论如何，我认为我找到了一个有趣的解决方案，事实证明 Alden Hart 的 TinyG 已经在做类似的事情。我们基本上将当前准确跟踪步数的 Bresenham 算法封装在跟踪时间的 Ranade 算法中。因此，从本质上讲，Ranade 算法将运行一个子计数器，该子计数器将在每次触发时递增 Bresenham 计数器。子柜台基本上是布雷森汉姆的另一个布雷森汉姆，如果这有任何意义的话。有了这个，不应该有除法，只是更多的整数加法/减法。

午餐时，我会测试这个概念，但我认为这会奏效。

好消息！这个概念有效并且运作良好。它也恰好使意想不到的事情变得更简单、更精简。还有很多工作要做。据我所知，这种方法唯一关心的是处理真正快速的 g 代码或弧的周期数，因此在测试构建发布之前进行大量优化和测试。

好的！新的步进算法已被推送到边缘分支，我在下载区域发布了一个构建。现在，它被限制在大约 15kHz 的步进速率，因为我还没有安装多步每步事件的想法。但是，该算法运行得比以前好得多。更清洁，更顺畅，并且几乎可以保证不会有任何打嗝。这里和那里可能仍然存在一些错误，但我的测试表明，使用这种新算法，我的 Sherline 磨机可以运行得更快，加速度更高。

如果你有时间，请在你的机器上测试一下，让我知道它是如何工作的（或不工作）。此外，如果您想尝试将步进频率提高到 < 30kHz，还有一些 config.h 选项。Ranade 算法目前以 20kHz 运行，这将步进速率限制为 15kHz，但您应该能够将其设置为 30-35kHz，并获得高达 25-30kHz 的更高步进速率。CPU 开销会增加很多，所以设置那么高时可能不会生成弧。无论如何，让我知道一切进展如何！

你好，我刚刚测试了这个。

G1 X1000 F20000 仍然可以正常工作，加速结束时没有砰砰声。

然而，F25000 及更高版本大约每秒发出一次重击，而不是仅在加速结束时。

将加速度设置为 1000，将 xsteps/mm 设置为 55。和 3us 步进脉冲宽度。

$0=55.208 (x, step/mm)
$1=400.000 (y, step/mm)
$2=400.000 (z, step/mm)
$3=3 (step pulse, usec)
$4=300.000 (默认进给, mm/min)
$5=1500.000（默认搜索，mm/min）
$6=252（步进端口反转掩码，int:11111100）
$7=25（步进空闲延迟，msec）
$8=1000.000（加速度，mm/sec^2）
$9=0.050（结点偏差，mm)
$10=0.100 (arc, mm/segment)
$11=25 (n-arc correction, int)
$12=3 (n-decimals, int)
$13=0 (report inches, bool)
$14=1 (auto start, bool)
$15=0 (invert step enable, bool)
$16=0 (hard limits, bool)
$17=0 (homing cycle, bool)
$18=0 (homing dir invert mask, int:00000000)
$19=25.000（归位进给，mm/min）
$20=250.000（归位寻道，mm/min）
$21=100（归位去抖动，毫秒）
$22=1.000（归位拉断，mm）

我知道这超出了步速，但我认为会有优雅的降级？即它只是以它可以管理的最高速度剪辑。

非常酷:) 设置…

#define ISR_TICKS_PER_SECOND 35000L // 整数 (Hz)

我能够做到

g1 x5000 f30000

它非常顺利，没有重击。

很好。

感谢更新！如果步频超过 Ranade 定时器频率，步频将被削波。这就是它的工作原理。因此，我们的想法是确保它始终大于您需要的最快步速，但不会更多，因为可用周期很快就会被吃掉。

听到 30kHz 有效，真是太棒了。:) 我很好奇是否还有足够的周期来执行弧线。如果你有时间，你能不能看看你能不能用 G2/3 画一个圆？我很确定它会窒息，但如果没有，可能没有任何理由进一步修改算法（每个刻度有两个步骤）。您可能需要将 10 美元的弧段长度增加到 1.0-2.0 毫米，以使其在高频步进速率下以低步进/毫米分辨率工作。

无论如何，让我知道更多的怪事或成功！

好的，我试过这个…

G17 G20 G90 G94 
G0 Z0.25
X-0.5 Y0.
Z0.1
G01 Z0. F5.
G02 X0. Y0.5 I0.5 J0. F2.5
X0.5 Y0. I0. J-0.5
X0. Y-0.5 I-0.5 J0.
X-0.5 Y0. I0. J0.5
G01 Z0.1 F5.
G00 X0. Y0. Z0.25

即使我只连接了一个轴，它似乎做得很好，我没有听到任何遗漏的步骤。

当然，如果没有实际绘图或切割，我无法确定。

谢谢@wolfmanjm所有的帮助。如果它正在运行，则几乎意味着它正在运行。当计划者跟不上步进器时，运动会很慢而且有些不稳定，不断地开始和停止。据我所知，规划器最多需要 4 – 5 毫秒来完成单个块的计算。因此，对于 0.1mm 段弧，这大约是 1200mm/min 的最大理论速率。但是，它可能比这要少一些。

如果您尝试进行新计算的速度过快，您知道每秒的砰砰声是多少吗？

它可以做几件事。如果您太接近定时器频率，那么您会在定时器频率和步进频率之间得到一些奇怪的谐波。你离得越近，它们就越明显。这就是为什么 20kHz 定时器频率有 15kHz 步进速率限制的原因。或者，如果您超出了定时器频率，您会得到一些步骤的剪辑，并且可能会导致步进计数器的整数溢出。

另一件事可能是，如果您正在流式传输具有许多非常小的线段的曲线（如弧线），那么您可能会饿死规划器缓冲区。规划器（还）没有对第一个块的覆盖保护。这意味着如果您挨饿，它可能会打嗝或做一些奇怪/坏事。否则，如果它总是满的，你应该没问题。

你能告诉我你要寄什么吗？我刚刚启动并运行了第二台更快的 CNC 机器，开始进行一些高速测试，所以我终于可以开始重新生产你所看到的一些东西了。

使用我上面显示的设置（55steps/mm 加速度 1000）而不增加 ISR_TICKS_PER_SECOND（只需将它们保留为默认值）。（我的步进驱动器设置为 16 微步）。

我在连接到驱动程序的原始步进器上运行它，甚至没有连接到 CNC。

如果我发出..

G1 X5000 F25000

然后它启动并运行，但运行时每秒钟都会有一次砰砰声。

如果我们有优雅的降级，我希望它以频率可以维持的最大速度运行，这可能比请求的速度慢很多，但不会每秒都有破坏性的重击。

另一种方法是忽略命令并发出错误并停止，无论哪种方式都可以，因为这是用户错误要求速度太高。

所以看起来它的运行频率约为 23kHz。超过 20kHz 定时器。可能发生的是每秒钟左右步进计数器溢出，并在步进生成中产生一个小间隙。因此扑通一声。我很确定如果你将 ISR_TICKS_PER_SECOND 增加到 24kHz 或更高，重击声就会消失。

对于 v0.9，计划为每个轴安装最大速度设置，所以我想这与您的想法一致。如果移动被缩小，它会自动以最快的速度移动并提供某种反馈。

是的，如果我将 ISR_TICKS_PER_SECOND 设置为 35000L，它不会产生重击，只是想你会想知道重击。

回到原来的话题。有没有人在使用新的步进算法减速结束时经历了额外的步骤？如果是这样，重现这个的参数是什么？

我试图用新的边缘（0.9 股票可下载）构建来寻找“重击”，但我再也找不到它了。这仅意味着在我最初的测试条件下它不再发生（即使我将事情拉伸得更高）。我确实尝试使用以下设置来捕捉它@wolfmanjm也是，但不能 – 这没什么，因为我的逻辑分析仪相当有限，并且无法在这些设置下捕获多秒的数据。显然，我什至没有尝试过实际的硬件——这些设置对我来说太高了。它可能仍然以这样的速度发生，每秒一次或其他情况，我无法确认 – 但对于我测试的原始案例，它肯定会消失。

伟大的。感谢您对此问题的更新。似乎这个问题已经用新的步进算法解决了，因为在最坏的情况下没有任何中断需要超过 25-30 微秒。意味着没有错过的中断滴答声，也没有砰砰声。我会保持这个线程打开一段时间，看看是否有其他人可能遇到这个问题。