注释
.jpg "关于边缘中的 Ranade 算法... #150"){kind=avatar}
|
是的，Pramod Ranade 算法几乎是一个 NCO。我将研究更新对 NCO 的所有引用，因为它已经是一个既定的算法而不是在线杂志中的东西。 因此，出于您陈述的原因，将 Bresenham 算法嵌入 Ranade/NCO 算法的主要原因有两个。 首先，Bresenham 算法在数学上保证完成多轴移动的所有步骤，即使是整数。这是因为步进事件计数/增量寄存器会自动缩放，无需担心舍入错误或猜测缩放乘数需要多少值才能避免它们。 其次，Ranade/NCO 算法本质上是在跟踪 Bresenham 算法的主缩放轴的相位，因此它在每次中断时仅跟踪和递增一个值。这显着降低了每个中断的计算开销。大多数时候它所要做的就是增加一相累加器并检查它是否需要增加加速度（不，它不必在每个周期都这样做，稍后会解释）。所以只要没有步进事件，大多数情况下，它通常会在大约 5 微秒内完成中断。 无论如何，这并不意味着我们不能让 Bresenham 算法像 Ranade/NCO 算法那样执行更独立的相位校正。您需要做的就是在分数阶段跟踪 Bresenham 算法，分数是 2 的幂（最低成本）。假设您将位移乘以相位累加器增量的两倍，位移乘以两倍的 Bresenham 触发 step_event_count，并保持其他一切不变，您基本上强制 NCO 算法每半个驱动波形周期触发一次，而不是整个周期。您还可以移动 Bresenham 计数器（但仍然精确）以一半的速率递增，但允许非驱动轴随时触发。所以它们变得更加正确。如果你继续以相同的方式乘以相位累加器的增量， 我还没有将这个想法应用到步进算法中，主要是因为这样的东西只能在低于 10kHz 的步进频率下工作。Arduino 根本不够快。我真的希望它有双倍的周期。 至于加速度，由于 Grbl 使用恒定加速度曲线，因此速度的斜率与时间成线性关系。因此，只要您通过具有恒定速度段的中点规则准确地追踪这条线，加速度的重建就是准确的。我这样做是为了进一步减少必须在每次中断时检查和递增加速计数器的计算开销成本。现在它每 100 到 200 次中断左右执行一次，由 int8 与 int32 跟踪。（至少那是它应该是的）。 |
我以前没听说过 Ranade 算法，但它听起来类似于 NCO（数控振荡器）——又名 DDS（直接数字合成）——相位累加器。（对于这个类比，我忽略了 DDS 中用于产生正弦波输出的 DAC 和滤波器，只关注高阶位翻转。）本质上，具有恒定相位增量值的 NCO 产生恒定频率脉冲序列. “线性扫描”NCO 产生恒定加速度脉冲串。线性扫描可以像在最新的边缘代码中一样通过按预定间隔增加相位增量寄存器来实现。但是，如果相位增量寄存器本身被视为累加器并通过每次向其添加加速度值来更新，则可以获得更高的精度循环。如果结果要在长距离移动中步进精确，加速度寄存器、相位增量（速度）寄存器和相位累加器必须是相当长的字。
我在我的分支中的独立移动代码 (limits.c: indep_increment()) 中实现了非常类似的东西。我的寄存器都是 32 位深，这可能有点矫枉过正，我的步进中断服务几乎是 54 微秒，而 grbl v0.8 代码不到 30 微秒。不过，这可能意义不大，因为我昨天刚刚测量了该时间并且没有尝试优化任何东西。
我的观点是，如果您实施高分辨率 NCO 算法，那么我认为您可以完全放弃 Breshenham 线算法。结构简化可能是值得的。也许 jgeisler 的模拟器将是测试纯 NCO 版本是否对协调的多轴移动步进准确的完美工具。
干杯，
查克