注释
|
@csdexter @blinkenlight: 你能否也给我一份你的前 10 个系统设置的打印输出？这也可以帮助我更快地找到这个问题。发生这种情况时通常需要多少步骤？ |
|
我听到的确实是每秒大约 10 步，最后大约 10 步，而且它似乎与进给速度无关。我刚刚用 0.7d 测试过，它做同样的事情。从 0.8 开始的设置如下： $$ |
|
谢谢（你的）信息。当前减少此问题的解决方案是在 config.h 中增加每秒的加速节拍。这种“停止前的超慢步骤”问题会因高加速度值而加剧，例如大约 80 mm/sec^2。对于某些运动，快速加速会使减速曲线近似不太准确，因此您往往会注意到更多这些额外缓慢的步骤。您还可以降低加速度值作为测试。你“应该”看到理论上的差异。 我现在可以做的一件事是增加我的 ACCELERATION_TICKS_PER_SECOND 以帮助缓解这个问题，但要真正解决它，它需要对步进器和规划器模块进行大量重写。我已经为下一个 v0.9 版本的进给率覆盖做了这个，所以当我到达那里时，我会确保看看我能做些什么来解决这个问题。 |
|
@blinkenlight: 如果你能够快速重新编译和重新刷写，你能帮我一个忙吗？我有一种预感，可能是其他原因导致了这种情况的发生。你能把 MINIMUM_STEPS_PER_MINUTE 从 800 减少到 100 或 300 之类的吗？看看会发生什么？它可能会提前达到这个限制，使其更加引人注目。谢谢！ |
|
@chamnit好的，我做了一个快速测试并使用 MINIMUM_STEPS_PER_MINUTE=100 重新编译。我不确定在运行过程中是否有什么不同（我不排除它可能是），但最后额外的步骤现在大约是~1Hz而不是~10Hz……另外，只是注意到了一些东西- 我正在使用旧版本的 Winder 的 Universal Sender 进行流式传输，最后，我在控制台中看到了这个（800 和 100）： ok grbl 0.8c [‘$’求救][‘$H’|’$X’解锁] 我不知道它以前是否存在（可能存在）-知道这可能是什么吗？有关系吗？ |
|
好，谢谢！这排除了一件事。您是否碰巧尝试将 ACCELERATION_TICKS_PER_SECOND 增加到 100 左右？这应该使它更短或消失。对不起，我不能自己做。我不在家，也无法在我的机器上重现此类错误。过去，这种类型的错误只会出现在某些设置上。 至于 Winder 的发件人，它与 v0.8c 不兼容。它必须更新以适应变化。所以发生的事情是发送者在完成流式传输程序后可能会发送 Crtl-X 软重置命令。它可能太早了几分之一秒。每当 Grbl 在循环运行时检测到重置时，它都会给你“循环中止”。MPos？错误。这只是意味着有一个不受控制的停止并且无法保证位置。 |
|
哎呀！使用“M2”命令进行了快速检查。只想确认一下。看起来“M2”不能正常工作会导致“循环中止”。MPos？错误。我今晚会努力解决这个问题。谢谢你让我知道。:) 无论如何，这不应该导致最后的缓慢步骤。 |
|
对不起，远离电脑。无论如何，结果：我已经把 MINIMUM_STEPS_PER_MINUTE 放回 800 和 ACCELERATION_TICKS_PER_SECOND 到 100L，它似乎没有改变任何东西 – 我们只是回到了预期的 10Hz 步骤。此外，您似乎对 M2 有所了解——它确实是最后一个命令，一旦我将其注释掉，错误就消失了。 |
|
有趣的。也许这不是我想的那样。我得看看发生了什么，看看是否有什么容易解决的。我猜从浮点数转换为整数时可能会出现一些舍入错误的问题。但是，由于这不是一个关键问题，我可能会等到我重新编写步进模块以进行进给率覆盖以完全解决问题。也就是说，如果我不能立即找到问题。 |
|
糟糕，发布在错误的问题线程中。有没有人使用新的步进算法在减速结束时体验过额外的步骤？ |
|
抱歉，还没有时间对新版本做任何事情。RL 真的很烦人。我会在一两天内尝试至少玩一点… |
|
终于有时间玩一下新版本（0.9 库存可下载） – 最初提到的“慢步”仍然在运行结束时发生，但它们变得更快：从假设的 ~10Hz 开始，它们似乎已经上升到大约 30Hz（现在我实际上有一个数字）。它实际上在 [1] 上以图形方式进行了描述 – 红色、蓝色和绿色是 X、Y、Z 阶跃信号。最后一步似乎进展正常（以减速结束），但随后是一些额外的缓慢步骤。知道这可能是什么吗？ |
|
是的，我确实有任何想法，我想我昨天碰巧修复了它，但我还没有推动它。如果我是对的，那么每当您以三角形速度分布而不是梯形分布移动时，都会出现此问题。这意味着移动没有达到标称速度。 解释如下：加速计时计数器在减速时重置为总计数的一半，以遵循计算速度的确切减速路径。如果步进算法达到标称速度并从规划器计算点开始减速，这应该没问题，并且不应该有缓慢的尾随步骤。如果步进算法直接从加速过渡到减速，则加速可能不完整，并且它应该处于的速度有点偏离和低。因此，当它开始减速时，它会过早到达目标位置。 数学上精确的解决方法是在加速 – 减速过渡时镜像加速计数器。基本上你从当前计数倒数然后继续。通过我这个周末的测试，它似乎已经解决了这个问题。我将努力将 Timer0 禁用和这个的修复推送到 v0.8c 主分支。v0.9a 边缘分支可能需要等待，因为它很混乱，有很多变化。 |
|
好的。我在 master v0.8c 和 edge v0.9a 分支上都发布了修复。还更新了可下载的固件。我希望这确实能解决这个问题。如果你有机会测试它，请告诉我。再次感谢@blinkenlight |
|
尝试了新的 0.8 和 0.9，我很高兴地报告“最后的额外步骤”和“细脉冲”问题似乎都消失了……干得好！:) |
|
伟大的！感谢您检查它们。多一双新鲜的眼睛来回顾这些事情总是很好的。我也会关闭这个问题。 |
尚尼特 评论 on 19 Nov 2012
将此对话移至新问题。以下是最初的消息。
blinkenlight：
这几天步进控制有什么变化吗？我在周末一直在测试 20121109 版本，但我仍然看到奇怪的 do-a-few-more-slow-steps-at-the-end-before-stopping tak-tak-tak-tak 行为我敢肯定我见过提到的某个地方（我只是不记得确切的位置）。我真的无法判断这些是错误的还是纠正性的额外步骤，但它看起来确实不太正确……
csdexter：
/me 举手
我是报告说奇怪的“最后阶段”加速行为的人之一。执行的总步数是正确的，但最后一次加速迭代有时太慢（就像@blinkenlight描述，你可以听到机器慢慢地做 5-10 步）。
我在运动开始时也看到过相同的情况（但很少见）：第一次加速迭代有时是无效的，表现为串行终端上返回“ok”和机器实际移动之间的可见暂停。
@blinkenlight：@csdexter:
奇怪的没有。我还没有真正接触过步进器模块，也没有接触过规划器模块。只改变了它们由一个状态变量管理的方式，而不是多个状态变量。然而，我确实将编译器从 Arduino IDE v1.0 更改为短暂使用 Crosspack for Mac，然后回到 Arduino IDE 但使用 v1.0.2。我注意到 Crosspack 使编译后的二进制文件显着变大，这就是我切换回来的原因。这可能是一种可能性。
所以，为了缩小范围，我需要你们俩提供更多信息。旧版本的 grbl 是否表现出相同的行为，例如 v0.7d 和 v0.8a？如果是这样，那么这是步进方案更固有的东西。第一个和最后一个速度步长非常接近于零，因此它有时会以如此缓慢的速度移动这些速度步长，以至于听起来像 tac-tac-tac。开始的总是在那里，但通常不引人注目，因为它是如此简短。由于数值舍入误差，最后一个速度步长可能会间歇性地引人注目。规划器并不是 100% 精确到步进模块中发生的事情，因此它可能会低于最终速度几十步，并使这种“超慢步”看起来更加明显。
config.h 中的 MINIMUM_STEPS_PER_MINUTE 设置是步进器可以移动的速度，它绝对是最慢的。它现在设置为 800 步/分钟，因此 13 步/秒是绝对最低速度。这是关于你听到的速率吗？调整此参数并增加 ACCELERATION_TICKS_PER_SECOND 也可能使此问题不那么明显。
如果这种行为仅在 v0.8c 上，那么，我手上有一个问题需要快速解决。