注释
作者
当然。引导消息如下。 为了进一步排除故障,我直接从 git zip 下载编译了一个“原始”版本,只更改了试驾机中的“#define N_AXIS 4”。我可以使用原始帖子中的测试程序 gcode 在试驾机上重现此问题。 使用我第一篇文章中的 $ 设置在“试驾”机器上重现的步骤: 引导消息:
|
所有者
我无法重复你所有的问题,但 ABC 总是表现得有点不对劲。 我发现并没有为这些轴初始化计数器。这为我清除了 DRO。 您可以尝试在 ABC_Stepperfix 分支上重新编译和重新测试吗? |
作者
谢谢@bdring. 我编译了你建议的分支,将测试运行设置为 4 轴,我一直观察到的行为消失了。DRO 现在按预期报告。我将为我的机器编译它并使用物理轴对其进行测试以确保 DRO 和物理轴仍然一致并报告我的发现。 |
所有者
我将更改与 devt 分支合并。将来使用它。 |
作者
感谢那。 确认我使用第 4 轴在实际工作中对此进行了测试,并且它按预期工作。没有奇怪的动作! 非常感激。 |
您使用的是什么版本的固件?
[MSG:Grbl_ESP32 Ver 1.3a 日期 20201101]
[MSG:Compiled with ESP32 SDK:v3.2.3-14-gd3e562907]
问题是否可重复?
是的
什么情况下会出现bug?
在代码中运行带有 A 轴运动的 g 代码程序。
当运行一个带有 A 轴运动的程序时,A 轴获得的额外度数超出了程序期间所命令的度数,并且超过了可接受的舍入/量化误差。这些往往会在程序的某个时刻同时发生。在紧接程序中第一个 A 轴移动之后的行中,它似乎是最可重复的。
当手动输入 gcode 命令移动 Z 轴时,我也能够观察到 A 轴的移动。同样,这似乎只发生在 A 轴从其“纯”零位置移动时。事实上,如果我在硬重置后运行一个没有 A 轴移动的程序,则 A 轴不会从“0.0”开始移动。但是如果我完全点动 A 轴(比如向前和向后 1 度)以便它计算“真实”位置(几乎不会在点动后返回到 0.0)并运行相同的程序,A 轴移动而无需命令.
我已经看到 A 轴从一步跳到 8 度!该错误反映在 DRO 和机器的物理轴上。一旦发生此错误,即使在 A 轴的后续运动之后,它也会继续执行程序的其余部分。据我所知,它只在给定程序中出现一次。请参阅下面运行测试程序的串行日志中的注释,其中轴在没有命令的情况下移动了 0.478(17 步)。
从两个不同的流媒体(bCNC 和 GrblGru)运行的代码观察到相同的效果。
显示错误发生的串行日志。(删除了“确定”行):
机器设置如下:
测试程序: