Grbl机器歪斜补偿 #709

我可以建议在 37 美元、38 美元和 39 美元的报告中再增加一两位小数吗？我用我的 CNC 来做 PCB，所以额外的精度很有用，而且能够以高精度查看当前值也很有用。

我通过更改 report.c 实现了它 – 例如更改

report_util_float_setting(37,settings.xy_skew_factor,N_DECIMAL_SETTINGVALUE);

到

report_util_float_setting(37,settings.xy_skew_factor,N_DECIMAL_SETTINGVALUE+2);

我可以建议在 37 美元、38 美元和 39 美元的报告中再增加一两位小数吗？我用我的 CNC 来做 PCB，所以额外的精度很有用，而且能够以高精度查看当前值也很有用。

我通过更改 report.c 实现了它 – 例如更改

report_util_float_setting(37,settings.xy_skew_factor,N_DECIMAL_SETTINGVALUE);

到

report_util_float_setting(37,settings.xy_skew_factor,N_DECIMAL_SETTINGVALUE+2);

为什么不直接修改config.h文件中的N_DECIMAL_SETTINGVALUE。我相信这样会更合适。

为什么不直接修改config.h文件中的N_DECIMAL_SETTINGVALUE。我相信这样会更合适。

因为 N_DECIMAL_SETTINGVALUE 在 grbl 的其他地方用于不同的目的？我认为更好的解决方案是添加 N_DECIMAL_HIGHPRECISION_SETTINGVALUE？

您还确定此修改不会破坏慢跑吗？我注意到当我在 Y 方向慢跑时 X 读数发生变化，更糟糕的是，当我在 Z 方向移动时。

好的 – 我相信我已经发现（并修复）了一个错误。在 motion_control.c 中，在 mc_line 函数中，您正在破坏“目标”数组的值（因为它是通过引用传递的）。我会尝试尽快在此处上传差异。

差异.txt

为什么不直接修改config.h文件中的N_DECIMAL_SETTINGVALUE。我相信这样会更合适。

因为 N_DECIMAL_SETTINGVALUE 在 grbl 的其他地方用于不同的目的？我认为更好的解决方案是添加 N_DECIMAL_HIGHPRECISION_SETTINGVALUE？

您还确定此修改不会破坏慢跑吗？我注意到当我在 Y 方向慢跑时 X 读数发生变化，更糟糕的是，当我在 Z 方向移动时。

如果你想将此的精确设置专门与 grbl 固件的其余部分分开，那肯定是一个可行的方法。

好的 – 我相信我已经发现（并修复）了一个错误。在 motion_control.c 中，在 mc_line 函数中，您正在破坏“目标”数组的值（因为它是通过引用传递的）。我会尝试尽快在此处上传差异。

正在更新目标值以直接在 mc_line 中反映偏移补偿，因为每件事都经过那个阶段并且该值不会向后使用（我的事情）（甚至不在 mc_arc 函数中）。在将该目标发送给计划者之后，计划者必须根据行进运动的实际点（我相信倾斜校正点）来做这件事。规划器只更新速度而不更新坐标。

任何慢跑运动都应该在你设置归位/开始位置状态之前发生，并且在 gcode 启动后不应该改变，所以如果我在那之后直接修改目标值也没有关系。不过，我会调查一下。尽管如此，这并不能解决慢跑问题。if (sys.state != STATE_JOG)在应用歪斜/反歪斜转换之前，应通过检查来解决点动问题。这将防止其他轴在点动时发生不必要的移动。

如果你想将此的精确设置专门与 grbl 固件的其余部分分开，那肯定是一个可行的方法。

grbl 以 10 纳米为单位来表达事物在IMO中是荒谬的。我有物理学背景，我被教导永远不要使用超过物理情况可能保证的小数位。

正在更新目标值以直接在 mc_line 中反映偏斜补偿，因为每件事都经过那个阶段并且该值不会向后使用

好吧，我可以根据经验告诉你。它似乎在链的更上层使用（在 gcode.c 中？）。既然我已经隔离了 mc_line 的变化（必然），那么我遇到的 X 轴奇怪行为的问题就消失了。

顺便说一句，我的 diff 也有一个错误，只有在轴数超过 3 时才会起作用。错误是我将值复制到 mc_line 中的“更正”数组中的地方。我真的应该做一个memcpy。

你是对的。它确实通过将最后一个位置存储在 gcode.c 中来使用坐标。
在这种情况下，应使用 memcpy，以便倾斜坐标不会影响 gcode 解析器。