看起来生成的 gcode 与 grbl 1.1 固件不完全兼容。硬限位触发的原因可能是主轴反电动势。如果您使用的是 usb OTG 连接，则很有可能会因为反电动势而中断。

尝试在没有主轴和没有木材的情况下运行机器以排除故障。

我可能不清楚。“<Run…”行不在我的代码中。它看起来像是控制器软件输出到控制台的机器状态。什么可能导致应用程序输出该行？如果应用程序在我的 g 代码运行时确实输出了该消息，那会导致错误 25 吗？我看到该行中有“FS”，可以将其解释为 g 代码字，我认为它们在同一行上不兼容。

另外，有没有办法将控制台输出发送到文件，以便我可以保留失败信息？我在三星平板电脑上使用 Grbl Controller v. 2.56。

我当然可以尝试重新运行该程序，但由于错误发生在运行约 4.5 小时后，我想先进行一些调查。有没有办法在调试模式下运行我的 g 代码？也许通过代码部分设置断点或单步执行？

谢谢。

“<Run|WPos:89.464,19.386,-9.375|Bf:0,39|FS:926,1”来自固件到应用程序控制台。不是由应用程序发送到固件（您可以将其关闭）

没有选项可以将控制台日志发送到应用程序中的文件。

“Error:25”来自固件，请检查生成的兼容性。

此应用程序不对 gcode 进行任何预处理，因此如果 gcode 与 grbl 固件不兼容，则它将无法工作（其他发送器如 UGS、Candle 可能会工作，因为它们对 gcoce 进行预处理并删除/转换任何不兼容的 gcode ).

在应用程序中有一个选项可以跳过错误 25（忽略不支持的 gcode 命令），您可以尝试一下。

“Alarm:1 Hard limit has been triggered”你需要找到解决这个问题的方法

我认为我的 gcode 不是问题。它由 Fusion 360 生成，我删除了 M6 命令。我以前用这个 gcode 雕刻过一块并且它有效。我再次查看代码，找不到任何会导致错误 25 的内容。代码的那部分是简单的 XY 运动。

固件状态消息是否有可能进入命令缓冲区？打印状态消息后，看起来在触发错误 25 之前还处理了 32 个命令。

此外，在检查工件后，似乎还执行了大约 25 条未输出到控制台的命令。在某一点，机器停止沿着雕刻路径前进，而是在 +X 方向上进行直线切割，直到碰到硬挡块。为了达到硬 X 切割开始的点，还需要执行大约 25 个未报告的命令。

看起来控制器在代码中丢失了它的位置并停止发送命令但没有停止机器。所以机器继续按照最后的指令路径和速度，在 +X 方向切割，直到到达硬停止。是否可以让控制器在失去缓冲区时停止机器？

我知道 EM 干扰会导致一些问题。我使用的是 USB OTG 连接，但有一根屏蔽线。正如我所说，我以前做过这个切割并且没有改变任何接线。不过，我会再看一遍。

如果你能帮我禁用固件状态消息，我会再试一次，看看效果如何。

谢谢。

您可以通过切换“详细输出”按钮来关闭固件状态消息

在此运行期间未启用详细输出。固件消息是如何通过的？

https://github.com/zeevy/grblcontroller/blob/master/app/src/main/java/in/co/gorest/grblcontroller/listeners/SerialCommunicationHandler.java#L73

仅当启用“详细按钮”时，机器状态消息才会显示在应用程序控制台中（错误和警报来自固件的所有其他消息未停止）

它是将固件输出到应用程序控制台的一种方式，而不是将应用程序控制台输出到固件。

主轴 EMF 可能会导致许多问题。要缩小问题范围，请在主轴关闭且没有木材的情况下运行机器。

还有一种可用的检查 gcode 方法（在应用程序和固件中）

我在没有主轴或木头的情况下运行了机器。由于上一次运行在大约 4.5 小时后停止，我将 Feed override 推到 200% 运行它。程序运行了大约 30 分钟就停止了。控制台上的最后一行是“<Run|WPos:98.231,47.903,-5.451|Bf:0,128|FS:246,0|Ov:200,100,100>ok”。就在那之前是一个典型的 XY 命令。

我重置机器并再次运行，这次没有 Feed 覆盖。程序在 2 分钟后停止。最后一行是“<Run|WPos:10.083,59.522,-6.333|Bf:0,128|FS:508,0|Ov:100,100,100>ok”。同样，前面是 XY 命令。

我想到了你所说的主轴反电动势。我对电不太了解，但我认为这可能是主轴上的额外负载造成的？由于主轴关闭，我想知道步进电机上的负载是否会导致类似的问题。

我检查了丝杠，它们看起来确实有点脏。我稍微清理了一下，然后重新上油。我再次运行该程序，它运行完成。也许一直都是我的错。你能理解这个吗？

我仍然很好奇为什么即使详细输出已关闭，机器状态消息也会发送到控制台。

谢谢。

应用程序控制台中的最后一行可能不是导致问题的实际命令，应用程序可能在确认错误之前发送了很多命令（这是由于固件中的 rx 缓冲区）。

应用程序中有一个选项将禁用此缓冲流“设置”=>“应用程序设置”=>“启用单步模式”。这可用于跟踪错误的 gcode 命令。

如果机器在进给率超过 100% 时出现故障，则步进电机可能没有获得足够的电流并丢失步数。（驱动器微步的增加也会降低扭矩）

由于来自各种来源的 emf，USB 连接可能无法正常工作。（蓝牙虽然不如 USB 快，但更可靠）

我今天执行的运行启用了单步模式，所以我认为命令历史记录是准确的。

如果脏丝杠导致运动缓慢，是否会延迟 ok 响应，从而违反状态更新间隔并允许机器状态消息通过？

在进给率 > 100% 的情况下均会发生故障。

gnea/grbl#1158

我今天执行的运行启用了单步模式，所以我认为命令历史记录是准确的。

如果脏丝杠导致运动缓慢，是否会延迟 ok 响应，从而违反状态更新间隔并允许机器状态消息通过？

在进给率 > 100% 的情况下均会发生故障。

我对此一无所知

谢谢你的提示。我已经订购了一些铁氧体，并且会告诉您它们是如何工作的。

抱歉，这花了这么长时间。仍然有一些问题，但我有理由确定这不是软件问题。这个问题应该关闭。

谢谢。