谢谢！我已经将该脚本用于复杂的、长达一小时的铣削作业，没有任何问题，但我偶尔会引入错误。我会尽快去的。

嗨，也许您的问题是由于 arc 命令引起的。他们目前不支持加速管理。因此，当您尝试以电机无法立即跳转到的进给率运行圆弧时，它们将会停止。我有一个类似的问题。

我启动了一个叉子，当我的工厂 ( http://www.youtube.com/watch?v=6DoqTpJEfDE ) 完成时，我将尝试实现一个允许加速管理的更快的弧算法。我已经有了一个在 MATLAB 中工作的概念。但这可能需要一些时间，因为我们刚开始买房子:-)

这是有道理的，因为我很幸运地运行了没有曲线的形状（星形、方框等），但是像这个文件（字母“J”）和另一个有椭圆的形状似乎就是它窒息。

我能做些什么来解决这个问题，也许是不同的 grbl 配置设置等？我正在使用自己制造的 2 轴激光器，并且仍在试验进给率等。

感谢您查看，我一定会发布我所做的任何成功更改！

至于现在，您可以为每个圆弧命令添加一个非常低的进给率。对我来说这很有效。

我一直在做一些实验，并且我对这个问题有更多的细节。

我将我的控制器升级到“边缘”固件，我能够使用 ruby​​ 脚本可靠地制作由直线组成的形状。但是，我仍然遇到弧线问题。

我生成了一些 gcode 来画一个圆：

G90
G21
G0 X22.8783 Y11.8311

M03
G1F30.000000
G02 X19.9515 Y4.9224 I-9.6173 J0.
G02 X12.722 Y1.9956 I-7.2294 J7.4652
G02 X5.4926 Y4.9224 I0. J10.392
G02 X2.5658 Y11.8311 I6.6905 J6.9087
G02 X5.4926 Y18.7398 I9.6173 J-0.
G02 X12.722 Y21.6666 I7.2294 J-7.4652
G02 X19.9515 Y18.7398 I0. J-10.392
G02 X22.8783 Y11.8311 I-6.6905 J-6.9087
G1  X22.8783 Y11.8311
M05

G0 X0.000 Y0.000
M05
M02

当我使用 ruby​​ 脚本将其流式传输到 grbl 时，圆圈的前半部分进展顺利。然而，当我们进入圆的第三个四分之一时，激光开始减速（这种加速开始了吗？），直到圆完成 3/4 时它完全停止。

现在，如果我使用终端手动输入 grbl 每行，同样的减速会发生，但是一旦达到 3/4 点，速度会再次缓慢增加，直到它在完成圆周时恢复到正常速度。

我将看看我是否可以更改/禁用加速以查看这是否有任何影响（也许我什至看错了方向）但是如果此信息提供了对问题的任何见解或者如果您有任何建议请通过他们一起。

谢谢！

ps 这是我当前的 grbl 配置：

$0 = 53.330 (steps/mm x)
$1 = 53.333 (steps/mm y)
$2 = 755.906 (steps/mm z)
$3 = 30 (microseconds step pulse)
$4 = 30.0 (mm/min default feed rate)
$5 = 480.0 (mm/min default seek rate)
$6 = 0.100 (mm/arc segment)
$7 = 0 (step port invert mask. binary = 0)
$8 = 25.0 (acceleration in mm/sec^2)
$9 = 50.0 (max instant cornering speed change in delta mm/min)

据我所知，弧总是在没有加速的情况下绘制的。他们应该跳到指定的速度（你的 F30）并以指定的速度运行，可能在每个 gcode 行之间有一个小问题。它们实际上是由很短的线条组成的。我真的不明白为什么你的电弧变慢了。您可以检查是否真的是步进变慢了，或者线段之间是否有断点。尝试玩 $6（毫米/弧段）。也许从 3mm 开始。
干杯，詹斯

你对弧线是正确的。他们在加速管理方面有些困难，我个人发现我根本不使用 arc-commands。我宁愿让我的 CAM 软件生成带有线条的近似值，因为它们无论如何都必须为任何其他曲线形状做。

我打算以安全速度运行电弧，该速度不应超过设定的加加速度限制。这可能是保守的，但老实说，由于一些愉快的个人情况，我在完成加速版本后没有太多时间使用 Grbl 进行生产。我期待尽快回到实验室并动手进行调整。在那之前：请随时向我提供有关如何解决这些问题的详细建议。

我刚刚尝试运行此代码，但我以 F1000 的进给率运行它。我的步进器的分辨率约为每毫米 157 步。所有的弧线对我来说都是一样的。我的问题在于弧段之间有一个明确的停顿。当进给率低时并不明显，但我确信它仍然会发生。我对此没有信心，但我认为发送命令行时会暂停。在阅读该行之前，它似乎停止了运动。这肯定是不好的，它使电弧无法使用。我不确定这是否会发生在海峡线上，但我会继续试验。

您观察到的行为是正确的。当前 grbl 在开始新弧之前等待缓冲区被清除。此外，发送线路后，在生成运动命令之前需要进行一些更复杂的浮点数学运算。
在我的叉子中，我正在进行一些修改，希望能使弧线更快、更平滑。但目前代码完全无法使用。只有 MATLAB 文件夹在一些简单的脚本文件中显示了基本的 Idea。Wiki 列出了计划的修改。
@simen: 很抱歉，我们以这种间接方式联系。我非常尊重你的工作，并且一直想写信给你分享一些想法，并可能为 grbl 做出贡献。但后来我不喜欢分享未完成的东西，因为我不知道什么时候能准备好，所以我不想过早做出任何承诺。我希望很快能更频繁地与您交谈。

没问题！我曾经在 grbl 的旧版本中有一个合适的整数圆插值器。它占用了大量的代码空间，而且非常复杂，我意识到我从未使用过 arc 命令，而是让 CAM 工具生成一个近似值。我同意，如果弧线在日常使用中很重要，那么代码就需要一些爱。我会欢迎一个精心制作的补丁或任何可能导致比我上次使用的更简单的插值器的建议。

但是看到弧线只是曲线特征的一种非常特殊的情况，我认为它应该被弃用。我可能错了。

我也遇到过类似的弧问题（UNO w/grbl edge）。我写了一个类似于 simen 的 ruby​​ 流脚本的 python 脚本。当我发送 g 代码块并在发送另一个块之前始终等待“确定”确认时，只要正在处理弧块，串口就会冻结。完成后，串行端口将再次打开以允许更多数据。很奇怪。这只会在处理弧线时始终如一地发生。如果缓冲区为空，这将导致意外停顿。

我设法通过在不等待确认的情况下强制使用预缓冲区来修补缓冲区等待问题，然后恢复等待“确定”（切换前刷新读取缓冲区）。只要缓冲区中还有另一个 g 代码块，我的 arc 测试 g 代码程序就可以顺利运行，没有任何问题。g 代码基本上创建了 2 个圆圈和 2 个带有内部圆角的正方形。每个弧都是 90 度或 180 度弧。处理弧线时仍然会发生串口冻结，但在执行其他操作时缓冲区会快速重新填充。

不相关的，我遇到了 arc 模式的 i 和 j 命令的问题。它不做全圆 360 块，并且在处理它时会做一些奇怪的事情。它偶尔会加速到无限速度并使 Arduino 崩溃。幸运的是，当它发生时，我的踏步机会发出一声响亮的高音呜呜声。到目前为止，没有对电机或驱动器造成损坏。

对于电弧，我真的很抱歉。事实是我真的很讨厌他们。它们在 G 代码和解析器中引入了很多复杂性，但仅代表曲线形状的一种非常特殊的情况。我个人从不使用它们，但是让我的 CAM 工具为我近似任何弯曲的形状。

对于 360 度 g 代码，这在技术上可能是一个应该修复的错误，但该标准建议您永远不要在单个命令中渲染超过 180 度的弧，因为舍入误差会在不同机器上产生不可预测的结果.

grbl 中 arcs 的高级实现很好，但我不得不承认实际的步骤生成有点简陋。弧强制同步是正确的，这排除了我为所有其他运动实现的良好流水线。作为一个厌恶 arc 的人，我犹豫不决：以一种漂亮而坚固的方式完成对 arc 的支持，或者把它全部撕掉并留给代码生成器。

是的。从技术上讲，您只需使用 G00 和 G01 即可完成所需的所有动作。使用 G02/03 的唯一原因是可读性、易于手写和直接编辑 g 代码。虽然很方便，但它不是必需的，因为它基本上是一个简单的固定循环。另外，就像你说的，你可以让一个功能强大的 CAM 系统为你做翻译，或者甚至是一个预处理器 Python/Ruby 脚本，它将 G02/03 块翻译和流式传输到 grbl。

在阅读了您的代码库之后，我明白了为什么很难使其精简和高效，特别是考虑到所需的计算量、将其集成到您的加速规划器中以及 Arduino 的空间限制。我会投票赞成从微控制器中完全去除弧形运动。相反，我会使用节省的 CPU 和内存来改进加速规划器并实施您提到的添加的那些功能：第 4 轴、PCM 输出到进给率以及状态/进度反馈。

我对 Python 相当流利，如果它对您的项目有用，我会尝试为 grbl 编写预处理器。这种方法的好处之一是可以更完整地实现 g 代码标准，即固定循环、可调进给率、单块执行等，同时保持 grbl 简单、高效, 并且灵活适用于许多应用。

感谢大家跟进此事。

仅供参考，我使用的是从 Inkscape 插件生成的 g 代码（我相信该插件是用 python 编写的）。因为我没有直接生成 g 代码，所以我不知道我可以控制它用来生成圆弧等的内容，但我可以使用后处理器，正如您所讨论的那样，将插头中的代码转换为-进入 grbl 更喜欢的东西。

当然我也可以重写插件，但我对 python 不是很熟悉，至少现在还不是。

如果您想出一些方法来进行此转换并需要帮助测试，请告诉我，谢谢！

大家好

我想开源的问题之一就是跟不上每个人。我已经将近一年没有在 grbl 上做任何工作了，但我确实花了一些时间在电弧失速问题上。我的大部分贡献都在这个提交中：

鲍勃盖茨@ e4b7919

我早些时候对 grbl 进行了更改，因为我引入了一个小型命令解释器，并且我试图完全摆脱阻塞。正如你们都知道的那样，Grbl 在线上已经是非阻塞的了，但是在弧线上停滞了，因为它们没有像弧线一样排队。我的代码标记了一条弧线，然后将其所有子线段排队。如果队列有 10 个命令，当弧中剩余的段少于 10 个时，它将允许另一个 g 代码指令进入队列，结果是下一个命令在弧之后立即开始。

我不能保证上面的提交是唯一需要改变的东西，后来有一些调试，但是看看组织如何绘制弧线的想法。它对我有用！我在 Simen 引入加速之前就这样做了，所以不能保证让它与加速一起工作可能需要什么。

嗨，鲍勃。除非您的修改很重要，否则我不明白为什么您的方法不适用于 Simen 的加速度曲线计算。您只需在新插值进入加速代码之前将其插入队列。这与我在 Arduino 上使用 Python 后（预）处理器将其转换为在 grbl 上最有效运行的程序所暗示的没有什么不同。

我担心的是 Arduino 在多任务处理方面不是最好的，也不是非常快。我怀疑如果你开始添加很多新功能，比如第 4 轴和状态报告，以及用于弧和其他东西的内部 gcode 转换器，你将开始限制 grbl 运行多个步进脉冲序列的速度。我建议尽量减少 grbl 必须在内部做的所有事情，但只添加它需要的功能，就像 Simen 已经在做的那样。

如果一切都是高效的，我不明白为什么 grbl 不能进化到运行 5 轴或 6 轴机器或六足机器人。问题是：要获得最大的灵活性和实用性，您需要的最低限度的功能是什么？

首先它看起来像 grbl 试图做 Bob 所说的，但我不确定为什么它被禁用，除了它可能在速度或其他方面对加速规划器不友好。在我回到家尝试之前不能确定。

供参考。我花了一些时间查看当前关于最佳进给率生成的研究，试图在外出工作时让自己忙碌起来。它看起来本质上是 g 代码插值和规划的问题。很难通过有限且不断变化的前瞻来即时计划，尤其是对于线性插值曲线。研究人员现在使用带约束优化方法的 b 样条曲线近似来求解预处理器中的曲线，并将曲线作为短参数集发送到控制器，以便在控制器中高效地动态重建它们。（参见 Timar & Farouki，2005 年，CNC 机器沿弯曲刀具路径的时间最优控制算法。）有一个更新的算法也考虑了较高速度下较低的电机扭矩。

这是正确的：chamnit。圆圈是通过缓冲许多微小的线段生成的。管理被禁用的原因是因为微型处理器刚刚在规划所有微型线路时窒息。一种可靠的解决方案是仅增加分段大小并重新启用规划。

有许多更高级的方法可以实现加速管理。我选择了一种简单的方法，我认为它足以满足您在典型家庭铣削中看到的那种进给率和刀具惯性。Grbl 中的管理器保证恒定的线性加速度，并将所有速度变化限制为特定的恒定加速度。此外，它允许用户接受速度的某种突然“跳跃”，这似乎会产生更合理的转弯。鉴于规划器仅查看未来的大约 10 个命令（由于内存限制），它可能会错过本可以继续以更高速度运行的机会。在这些情况下，规划器会偏低以保证永远不会超过设定的加速度。根据我使用 Grbl 进行铣削的经验，这没有实际意义。

理想情况下你想管理“混蛋”（加速度随时间的变化（加速度派生）），但我认为这种方法不适合有限的平台，并且很难用简洁的代码表达我更喜欢这个项目。

很公平。我读过的大多数关于高级进给率规划的文献在现实世界中实施方面仍然非常幼稚，或者仅适用于大批量生产的高速加工。看到这样的东西作为开源会很有趣，也许在某个时候我会把这个毕达哥拉斯-hodograph 方法作为一个副项目来试一试。

另外，前几天我才注意到 jgeisler0303 的 fork 刚刚发布了一个重写的支持弧的规划器。看起来它删除了 sin() 和 cos() 计算，并用计算效率更高的计算替换它们，以使其与规划器一起工作。我不确定他与当前的 grbl master/edge 相比有多少变化，但我会尝试看看。

我提交的代码又是非常原始的（很多注释的 printf 调试行并且没有经过很好的测试）。无论如何我都犯了，所以完美主义不会导致我从不这样做。我已经知道有两个小错误，但在我现在完成的磨机上的第一次运行显示了非常令人满意的结果。

The code is a major rework with many new features (better homing, e-stop on limit switch tripping, instant abort with deceleration, jog-wheel mode) and – apart from the arc routine – a totally new and hope fully faster planner. Pulling this back upstream will be a pain, but it’s not yet the time to thing about that.

Apart from my efforts to get arcs with acceleration management, I totally agree that the atmega should primarily run the real-time code and in the future should get a front-end like EMC2 that does preprocessing, GUI and stuff. Directly integrating something like grbl or teacup in EMC2 is probably not possible because of its whole architecture (it is very universal and carries the huge overhead for feedback control of dc motors).

For now I did the arcs because I wanted some kind of “hand operated” cnc mill to get a better feel for milling and gcode.

I implemented a controlled jerk acceleration solution for the tinyG project – it’s open source and found at https://github.com/synthetos/TinyG. Simen and I have discussed this at various times – the math in the jerk equations is not that compatible with the Arduino ATmetas. TinyG runs an Xmega chip. Look-back replanning is 16 moves – again for memory space. I’ve been working on the physics behind optimal cornering and will post that as I have results to show.

Hi Alden. Can you elaborate on what you mean by the math is not compatible with the Arduino ATmegas?

I’ve been looking into the physics of optimal feedrates as well. The feedrate/acceleration problem is highly nonlinear and path dependent, which generally requires an constrained nonlinear optimization method for a true solution, which the Arduino cannot do on-board realtime. I have seen other algorithms in literature that do more robust versions of Simen’s approach, but still these cannot be done on the Arduino realtime. Although, if you make some assumptions, there may be a simpler and more efficient method than the one Simen has now, but I haven’t found a decent solution as of yet.