自从 2011 年我开始从事这个项目以来就没有了。这是我修复的第一件事。在此之前，Marlin 就被分叉了。

您不会碰巧有一个提交 ID，对吗？如果没有，我很乐意搜索责备日志。

这看起来像一个潜在的候选人…… d75ad82 #diff-a4eaa8474f0ada716c21c0d502f87a6dR132

-  planner_reverse_pass_kernel(NULL, block[0], block[1]);
+  // Skip buffer tail to prevent over-writing the initial entry speed.

I’m going out on a limb and betting grbl still has this issue. After much studying of the code, without guidance, I cannot see why it would not. Please test the posted G-code and see if it performs correctly.

@thinkyhead : Nope. Grbl runs just fine. There hasn’t been a significant motion issue in several years, which is the main reason why its so popular, even though its restrictive and simple. What you are likely seeing is a buffer starvation or inability to plan the path quickly enough and causing a desync between execution and the planner. The fixes in Grbl are subtle, but are exact. They account for failure conditions gracefully.

Thanks much. A lot to digest in studying the updates to your implementation.