注释
当然。引导消息如下。 执行进一步的故障排除,我直接从 git zip 下载编译了一个“virgin”构建,只更改了测试驱动机器中的“#define N_AXIS 4”。我可以使用我原始帖子中的测试程序 gcode 在试驾机器上重现此问题。 使用我的第一篇文章中的 $ 设置在“试驾”机器上重现的步骤: 引导消息:
|
我无法重复你所有的问题,但 ABC 总是表现得有点不对劲。 我发现并没有为这些轴初始化计数器。这清除了 DRO 对我的影响。 您可以尝试在 ABC_Stepperfix 分支上重新编译和重新测试吗? |
谢谢@bdring. 我编译了您建议的分支,并将测试运行设置为 4 个轴,并且我一直观察到的行为消失了。DRO 现在按预期报告。我将为我的机器编译它并使用物理轴对其进行测试,以确保 DRO 和物理轴仍然一致并报告我的发现。 |
我将更改与 devt 分支合并。将来使用它。 |
感谢那。 确认我使用我的第 4 轴在实际工作中对此进行了测试,并且它按预期工作。没有奇怪的动作! 非常感激。 |
探索设备 评论 on 19 Nov 2020
您使用的是什么版本的固件?
[味精:Grbl_ESP32 Ver 1.3a 日期 20201101]
[味精:使用 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)运行的代码观察到相同的效果。
显示错误发生的串行日志。(删除“ok”行):
机器设置如下:
测试程序: