我在 GRBL 的问题页面上发布了相同的内容，但我在这里复制它可能与 bCNC 相关：

我尝试切割 4 个简单的圆形凹槽并使用 jscut 的斜坡功能（即，它不是直线切入，而是斜坡进入所需的 Z – 或在我的圆形凹槽中创建螺旋运动，以优化刀具寿命）。结果是大约 9k 行 gcode，其中一半涉及 Z 移动。

运行 gcode 后，我注意到它回到了给定的 3mm 安全高度（Z WPos 确实显示 3），但实际上高出两倍左右。这是我调试它的思路。

• 错误的 102 美元：这是我最初的想法。然而，错误的 102 美元只会导致缩放问题（即，如果它更高/更低，我的 Z 移动将按比例压缩/扩展）。然而，从 Za 移动到 Zb 再回到 Za 应该去同一个 Za，即使这超出了比例。就我而言，Za 随着时间的推移而变化！然后我尝试手动给出 30~40 个 Z 移动，它们都是一致的（顺便说一句，比例也是正确的）。Z0总是会回去亲吻腰板。所以无论发生什么，都会在 1000 秒的 Z 移动之后发生。
• 探测问题：我在腰板上的不同位置进行探测，当转到 G1 Z0 时，它是正确的。没有探测/归零问题。
• 跳过的步骤：这是下一个要质疑的领域。但是，没有跳过步骤的迹象/声音。此外，让我排除这个的是一致性。它总是会移动相同的。“空切”时即使空载。
• 腰围不水平：结果也无关紧要。尽管我确实计划很快对腰板进行面铣削，但我还是在相同的 X、Y 上进行了 Z 位移比较（在运行 gcode 之前和最后）。
• 工具打滑：这是一个可能的解释。如果出于某种原因工具没有足够紧密地接合夹头，并且切割过于激进，那么理论上工具可能会向上滑动并呈现出我所经历的（这是一个很好的想象来想象实际发生的事情）。然而，这也是没有问题的……因为，再次，当“空气切割”时，最终会发生向上的 Z 偏移（相同的量）！

我剩下两个（我能想到的）可能的罪魁祸首。

• 缓冲：如果由于某种原因某些 gcode 从流中取出，我会看到 Z 偏移。然而，我正在向下切割并且向上移动的事实使得这种情况不太可能发生。此外，我正在使用 bCNC，它应该是（或至少是其中之一）在流式传输大量 gcode 方面的最佳表现者。
  编辑：嗯…如果向下的 Z 移动在缓冲时下降，bCNC 是否可以认为主轴低于它，以便随后的向上 Z 移动会使它进一步向上移动？正是这种情况以相同的模式一遍又一遍地发生，这让我感到困惑。
• 四舍五入：这是我唯一没有调试过的。我使用的是 ACME，因此我的 102 美元很难看：
  (200step/rev * 2microstep/step) / (25.4mm/in / 12rev/in) = 188.976microstep/mm

这让我想知道 1000 次 Z 舍入是否足以导致 Z 偏移。我今天想尝试的一件事是用一个不错的整数（比如 200 微步/毫米）将我的 102 美元超出比例，看看相同的 gcode 是否仍然导致 Z 偏移。

顺便说一句，我正在使用带有 GRBL 版本 1.0c.20151109 的 X-Controller。

任何想法，建议都非常受欢迎。