使用您的示例代码，这在模拟中看起来可重现。发生这种情况的原因是因为 2.7 轨迹规划器允许同步运动之间的混合。这是有和没有停留时轴加速度的比较：

没有驻留（在 X 轴上有过加速）：

随着驻留，只有 Z 轴加速度：

造成这种差异的原因是 2.7 TP 允许在正常进给移动（G1、G2 等）和位置同步移动（G33）之间进行混合。这会产生一个小的混合弧（如您所观察到的）。

进一步研究，我发现（正如预期的那样）2.6 TP 在开始 G33 移动时不允许混合。但是，它确实允许在 G33 移动结束时混合。此 G 代码片段显示了轴模拟配置中的行为。在2.6中，N5之后会有一个精确停止，但是N6和N7之间会有一个混合。

N1 G20 G64 G8 G18
N2 M3 S500
N3 G0 X2.0 Z0
N4 G0 X1.1 Z0.1
N5 G1 X1.0 Z0.0 F200
N6 G33 K0.1 X1.0 Z-1.0
N7 G1 X1.1 Z-1.1 F200  
N8 G0 X2.0
N9 G0 Z0
N10 M5
N11 M2

因此，在 G 代码示例中，2.6 TP 在启用位置同步的情况下应用以下规则：

1. 从 G1 过渡到 G33（准停）
2. 两个 G33 运动之间的过渡（使用路径设置）
3. 从 G33 过渡到 G1（使用路径设置）

我在基于最新 2.7的修补程序分支中对此进行了修复。不幸的是，在边缘情况下可能会出现一个更微妙的问题。采用以下 G 代码示例，它遵循主轴同步中的锯齿形路径：

G20 G64 G8 G18
M3 S100
G0 X1.1 Z0.1
G1 X1.0 Z0.0 F200
G33 K0.1 X1.0 Z-1.0
G33 K0.1 X0.75 Z-1.5
G33 K0.1 X0.75 Z- 2.0
G1 X1.1 Z-2.1 F200
G0 X2.0
M5
M2

在粗线之间，即使进给速度非常慢，创建的混合弧也相当大：

圆弧很大，因为 TP 不知道位置同步运动的计划主轴速度。相反，它使用段的最大可能速度。我们可以通过在主轴同步运动期间完全防止圆弧混合来解决这个问题，但仍然允许抛物线混合。有了这个改变，我们将拥有所有位置同步动作的 stock 2.6 行为。

另一种稍微复杂一些的方法是使用状态标签之类的东西将计划的主轴速度传递给 TP 。知道所需的主轴速度后，我们就可以预测目标速度，并调整混合弧的大小以匹配（而不是假设最坏的情况）。

@SebKuzminsky @cradek您如何看待这些修复？

我认为在 2.7 中在主轴同步移动结束时进行 2.6 风格的混合可能会很好，只是因为这听起来很简单并且很容易在稳定分支中得到正确的结果，并且众所周知它可以为线程提供良好的结果拉出。在同步移动结束时不停止很重要，正如我在此处尝试解释的那样。

@cradek你的解释很有道理，我的修补程序分支现在应该更新以反映 2.6 的行为。

您知道是否需要沿复杂路径进行位置同步运动？如果不是，我们可以通过限制位置同步运动使用抛物线混合来解决大混合弧问题。然而，这将导致引入运动稍长一些，因为加速度将减半。

公差会影响主轴同步运动的混合吗？(g64Px.xxx).. 如果你想让路径更好地遵循（或尝试）你能指定它吗？

我认为沿复杂路径的同步运动极为罕见，但已被使用。你说的引入时间越长越重要，但我觉得没问题；我从来没有听过有人说由于空间有限他们无法管理导入。我想线程的本质是一端暴露……

我已经切割了多个看起来像大金属板螺钉的锥形螺纹，当然还有管螺纹上的锥形末端。
我认为在每转进给模式下我们不需要任何混合（G33 到 G33）或 G33 到 G1。
您只是在第一个 G33 之后不重新同步。PID 将处理轻微的加速度变化。
如果角度差异超过 30 度左右，您可能需要混合。

就铅而言。一些数控车床喜欢在螺纹加工时以转速 (M4) 运行。然后您必须在槽中开始螺纹并进给 Z+。在这种情况下，引入线应尽可能短。我会说在 400 到 500 RPM 时小于 2 或 3 毫米。

我这里有一个实验分支，可以解决这个问题，并提高与 G33 运动的混合性能：

https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/nominal-vel-during-sync

有关性能改进的详细信息，请参见#164

这和#704一样吗？

我对 704 的建议是记录行为。我认为在两个主轴同步移动之间暂停是没有意义的，

在两个连续的 G33 移动之间强制同步索引的最佳方法是什么？
我将尝试测试虚拟 G0 或 G1 是否退出 G33“模式”

这个现在是什么情况？
b3fa297是帮助还是阻碍？

这个现在是什么情况？
b3fa297是帮助还是阻碍？

我不认为它完全解决了原始问题（G1 和 G33 之间的混合），但它是 2.7 的必要修复（截至今天早上最新的 2.7 分支仍然显示#704行为）。

希望由#890修复