我认为我在 V0.8c 上遇到了相同或类似的问题。我将运行一个程序（在简单的 3 轴 CNC 工作台 a la Skapeoko 上），它会在我重新获得对机器的控制之前通过强制硬重置部分冻结。UGCS 记录一个报警故障。我安装了限位开关但禁用了，因为尽管 LS 线上有屏蔽电缆、电容器和铁氧体，但它们仍然太抽搐。（我只是在设置过程中启用限制和归位，然后在运行零件之前禁用，这样错误的触发器就不会让生活变得更加困难）。我真的会完美地切割一个零件几次，然后再次运行程序并让它随机冻结。

我真的很困惑是什么原因造成的。除了触发限位开关之外，还有哪些其他条件会发出警报？想知道我是否在触发警报的电机信号线上受到间歇性干扰。

急于追查这个问题的根源。

@Mgilbride：据我所知，Grbl v0.8c 相当稳定，您不应该遇到这些类型的错误。Grbl v0.9b-c 的开发版本仍然存在一些问题，因此这里是停止问题。绝大多数情况下，此类问题是由外部来源引起的，至少来自过去的用户问题。首先，我将消除可能导致此问题的任何外部电噪声源，因为如果您有嘈杂的限位开关，那么这清楚地表明某些东西没有正确接地或其他东西。确保所有东西都通过星形接地共享同一个接地，以防止接地回路。确保所有电缆，尤其是与 Grbl 通信的 USB 电缆，远离任何潜在的电气干扰源。（如果没有，请尝试使用屏蔽 USB 电缆。它们更粗。) 最后，将您的流媒体程序作为变量消除。在我们的 repo 或其他使用不同库的 GUI 中尝试我们的 Python 流脚本。

如果您仍有问题，请不要犹豫，发布您的发现。另外，如果你解决了它，请告诉我们你做了什么来解决它。谢谢！

谢谢。我会试试这些。特别是消除软件并
添加（或确定我是否正在使用）屏蔽 USB 电缆。

我正在使用星形地面，但会再次对其进行审查。

我的电子产品与电源一起装在一个外壳中。一个
可能不寻常的细节是我的
控制器/驱动器盒中有一个 110 插座。它由为电源供电的同一主线
供电。我目前使用该插座为我的修剪路由器供电。我唯一
关心的其他细节是两条电机信号线和一条限位
开关线确实在拖链中平行运行。一切都被屏蔽了。
路由器的电源线上有一个铁氧体。只是还没有想出一个
实用的替代路由。其他细节是我的钻机很大。
基本上是 4×5 英尺。所以我的信号线变得很长，这肯定会让
事情变得复杂。

我只能说的另一件事是，我认为，但不确定，这
总是在弧线期间发生。我记得这种情况发生的所有时间都是
在弧形或圆形切割期间。但是，我很确定我疯了，因为这些程序确实可以完美运行， 除了重置之外
没有任何硬件、软件或编程更改。

会及时向大家发布。感谢您的精彩固件！

2014 年 1 月 25 日星期六下午 1:45，Sonny Jeon notifications@github.com写道：

@Mgilbride https://github.com/Mgilbride：据我所知，Grbl v0.8c 非常稳定，
您不应该遇到这些类型的错误。
Grbl v0.9b-c 的开发版本仍然存在一些问题，因此
这里是停止问题。绝大多数情况下，此类问题
是由外部来源引起的，至少来自过去的用户问题。首先，我
将消除可能
导致此问题的任何外部电噪声源，因为如果您有嘈杂的限位开关，那么这
是一个明确的指标，表明某些东西没有正确接地或其他
东西。确保所有东西都通过星形接地共享同一个接地，以
防止接地回路。确保所有电缆，尤其是您的 USB 电缆
与 Grbl 通信，远离任何潜在的电
推理源。（如果没有，请尝试使用屏蔽 USB 电缆。它们
更粗。）最后，将流媒体程序作为变量消除。
在我们的 repo 或其他使用
不同库的 GUI 中尝试我们的 Python 流脚本。

如果您仍有问题，请不要犹豫，发布您的发现。
另外，如果你解决了它，请告诉我们你做了什么来解决它。谢谢！

—
直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/336 #issuecomment-33296412
。

你好

我有同样的问题。
我在 Arduino Mega 2560 和 GrblController 上使用 grbl 进行 GCode 上传。

http://zapmaker.org/projects/grbl-controller-3-0/

grbl 通常在批量上传后冻结在完全相同的位置。
我以多种方式编译了 grbl，具有不同的波特率、缓冲区大小等……它们没有影响。

GrblController 有一个选项“Aggresive Preload”…当我将其设置为 OFF 时，它不再冻结…但这有一个缺点是命令之间有短暂的延迟（GrblController 在发送下一个命令之前等待 OK ）。

我什至尝试手动发送命令。一次发送一个命令时，它们会完美执行。但是当它们被批量发送时……这就是它发生的时候。

目前我没有安装限位开关。

锁定后，我必须重置连接才能让 grbl 再次工作。

谢谢！

@robertnino: 你用的是哪个版本的 grbl？您是否尝试过使用不同的流媒体程序？您还在流中发送任何 G54-59 命令吗？访问 EEPROM 的某些命令尤其会导致 v0.9c 出现某些问题。我现在也在努力解决这个问题。

去年我在 UNO 上使用 0.8c、Zapmaker 和激进的预加载时遇到了同样的问题。我需要预加载，因为标准加载的命令序列太慢。它通常会在序列结束之前锁定。经过大量测试后，我发现这取决于我在代码结束前使用的浮点命令的数量和精度。这不是缓冲区溢出。就我而言，我经常使用 G4 Px.xx 来精确计时转台和相机快门。Zapmaker 说这是因为 GRBL 如何处理 G4 命令，这与模态操作有关。我有一个 100% 可重复的短代码序列。如果有人有兴趣，我可以挖掘它。

-安迪

发件人：Robert Voinea [ mailto:notifications@github.com ]
发送时间：2014 年 1 月 28 日，星期二 1:30 AM
收件人：grbl/grbl
主题：回复：[grbl] grbl 0.9c – 在批处理一些 gcode 命令后停止工作（# 336 )

嗨
我有同样的问题。
我在 Arduino Mega 2560 和 GrblController 上使用 grbl 进行 GCode 上传。
http://zapmaker.org/projects/grbl-controller-3-0/
grbl 通常在批量上传后冻结在完全相同的位置。
我以多种方式编译了 grbl，具有不同的波特率、缓冲区大小等……它们没有影响。
GrblController 有一个选项“Aggresive Preload”…当我将其设置为 OFF 时，它不再冻结…但这有一个缺点是命令之间存在短暂的延迟（GrblController 在发送下一个命令之前等待 OK ）。
我什至尝试手动发送命令。一次发送一个命令时，它们会完美执行。但是当它们被批量发送时……这就是它发生的时候。
目前我没有安装限位开关。
锁定后，我必须重置连接才能让 grbl 再次工作。
谢谢！
—
直接回复此电子邮件或在 GitHub #336（评论）上查看。图片已被发件人删除。

我忘了补充。Zapmaker 在他的下载器中添加了几行代码（在 3.something 中），基本上说“如果 G4 Px，等待“OK””。这解决了 grbl-controller 的问题，但让我的代码太慢了。

安迪

发件人：Andy Nobbs [ mailto:andy_nobbs@yahoo.com ]
发送时间：2014 年 1 月 28 日，星期二上午 8:17
收件人：’grbl/grbl’
主题：RE：[grbl] grbl 0.9c – 在批处理一些 gcode 命令后停止工作（#336）

去年我在 UNO 上使用 0.8c、Zapmaker 和激进的预加载时遇到了同样的问题。我需要预加载，因为标准加载的命令序列太慢。它通常会在序列结束之前锁定。经过大量测试后，我发现这取决于我在代码结束前使用的浮点命令的数量和精度。这不是缓冲区溢出。就我而言，我经常使用 G4 Px.xx 来精确计时转台和相机快门。Zapmaker 说这是因为 GRBL 如何处理 G4 命令，这与模态操作有关。我有一个 100% 可重复的短代码序列。如果有人有兴趣，我可以挖掘它。

-安迪

发件人：Robert Voinea [ mailto:notifications@github.com ]
发送时间：2014 年 1 月 28 日，星期二 1:30 AM
收件人：grbl/grbl
主题：回复：[grbl] grbl 0.9c – 在批处理一些 gcode 命令后停止工作（# 336 )

嗨
我有同样的问题。
我在 Arduino Mega 2560 和 GrblController 上使用 grbl 进行 GCode 上传。
http://zapmaker.org/projects/grbl-controller-3-0/
grbl 通常在批量上传后冻结在完全相同的位置。
我以多种方式编译了 grbl，具有不同的波特率、缓冲区大小等……它们没有影响。
GrblController 有一个选项“Aggresive Preload”…当我将其设置为 OFF 时，它不再冻结…但这有一个缺点是命令之间存在短暂的延迟（GrblController 在发送下一个命令之前等待 OK ）。
我什至尝试手动发送命令。一次发送一个命令时，它们会完美执行。但是当它们被批量发送时……这就是它发生的时候。
目前我没有安装限位开关。
锁定后，我必须重置连接才能让 grbl 再次工作。
谢谢！
—
直接回复此电子邮件或在 GitHub #336（评论）上查看。图片已被发件人删除。

@lakeside53：请发布您的示例代码的链接。我很好奇是什么导致了这个问题。这听起来像是流媒体客户端方面的流媒体协议问题，主要是由于可疑的“IF G4”声明。这可能意味着 Zapmaker 使用的流媒体协议可能不完全兼容。对于某些命令，如 G4 暂停或 M3/4/5 主轴控制，Grbl 必须清空其缓冲区以完成队列中的所有运动，以便按时按编程执行命令。G2/3 弧暂停流式传输以将小线段注入规划器缓冲区。如果流媒体程序并不总是提供“OK”响应，您将遇到您所描述的问题。在我们的高级流脚本中，通过跟踪发送的字符和“ok”响应的数量，同时保持 Grbl 的串行输入缓冲区满，有一些方法可以提高和强大的流性能。不过，我仍然会针对我们的流脚本进行测试，以确保它不在 Grbl 的末尾。

仅供参考，Grbl 的模态操作主要是由于内存限制，但如果事情正确地流式传输到 Grbl，它不应该真正影响性能或事情的运行方式。使 Grbl 非模态仍然是可能的，因为我一直在为此寻找简单而干净的解决方案，但这不是优先事项。基本上，它将涉及必须将任何非运动 g 代码块命令存储在内存中，并在步进模块完成前一个块时执行它们。

我搞砸了——Zapmaker 加入了“if Mx”修复，而不是“if G4”。对不起，那是从去年四月开始的，自从他们 J 之后发生了很多事情

我可以发送整个文件，但它们只是重复序列——旋转表执行短序列、旋转表等。

问题在于程序序列如何终止。我可以为其提供足够的数据以全速长时间（数小时？）执行以下操作，并且在退出之前不会失败。

以下两个示例之间的唯一区别是 G4 P0.11 有效，而 G4 P0.1 失败 – 但仅在程序退出时。需要明确的是——每个命令都按预期工作，但我无法重新控制 GRBL 我在后来的实验中发现我可以通过简单地添加一些“什么都不做”G 代码来解决这个问题（比如定位一个不存在的Z 轴）在最后一个序列之后，但在 M30 之前（参见最后一个示例）。如果使用“积极的预加载”，这只是一个问题；命令的标准加载速度要慢得多，但它可以工作。我是移除 M30 还是将它留在里面都没关系。

Zapmaker 提出的“if M7”修复只是一个快速解决问题的方法，但我不得不删除它，否则我的速度优势就消失了。就我而言，积极的预加载是要走的路。我必须查看他的最新代码，看看它是否仍然存在。如果您想知道……速度和设置延迟的能力很重要。在下面的“积极预加载”序列中，我可以在大约 30 秒内拍摄 90 张高分辨率照片（相机是限制因素）；没有预载大约需要 1.5 分钟（grbl 限制）。将其乘以数千个序列，然后……

为了清楚起见，我在伪造一个旋转轴

这每次都有效（grbl 0.8c）

G92 X0（零 X = 当前位置）
G0 X-2（后退一点以设置正向间隙）

G0 X0（从这里开始）
G4 P0.11（宝石稳定延迟）
M8（快门释放-开启，使用冷却液控制）
G4 P0.12（在运动前等待图像读取，并允许快门速度）
M9（快门释放 – 关闭）

G0 X4（下一个位置（4 毫米/英寸 = 度）
G4 P0.11
M8
G4 P0.12
M9

G0 X8
G4 P0.11
M8
G4 P0.12
M9

…..
为清楚起见删除了代码通过将 X 增加 4 – “度”步骤重复序列。
……

G0 X352
G4 P0.11
M8
G4 P0.12
M9

G0 X356
G4 P0.11
M8
G4 P0.12
M9

M30（停止）

每次都在退出时失败（grbl 0.8c）：

G92 X0（零 X = 当前位置）
G0 X-2（后退一点以设置正向间隙）

G0 X0（从这里开始）
G4 P0.1（宝石稳定延迟）
M8（快门释放 – 打开，使用冷却液控制）
G4 P0.12（在运动前等待图像读取，并允许快门速度）
M9（快门释放 – 关闭）

G0 X4（下一个位置（4 毫米/英寸 = 度）
G4 P0.1
M8
G4 P0.12
M9

G0 X8
G4 P0.1
M8
G4 P0.12
M9

…..
为清楚起见删除了代码通过将 X 增加 4 – “度”步骤重复序列。
……

G0 X352
G4 P0.1
M8
G4 P0.12
M9

G0 X356
G4 P0.1
M8
G4 P0.12
M9

M30（停止）

这“修复”了退出上述“总是失败”序列的问题：
与上面的代码相同，但 4 行“什么都不做”（就我而言）。不确定我是否需要这一切，但是……
。

……

G0 X356
G4 P0.1
M8
G4 P0.12
M9

（停止前一段时间什么都不做）

G92 Y0
G0 Y10
G0 Y-10
G0 Y0

M30（停止）

发件人：Sonny Jeon [ mailto:notifications@github.com ]
发送时间：2014 年 1 月 28 日，星期二 10:09 AM
收件人：grbl/grbl
抄送：lakeside53
主题：回复：[grbl] grbl 0.9c – 在批处理一些 gcode 后停止工作命令（#336）

@lakeside53 https://github.com/lakeside53 ：请发布您的示例代码的链接。我很好奇是什么导致了这个问题。这听起来像是流媒体客户端方面的流媒体协议问题，主要是由于可疑的“IF G4”声明。这可能意味着 Zapmaker 使用的流媒体协议可能不完全兼容。对于某些命令，如 G4 暂停或 M3/4/5 主轴控制，Grbl 必须清空其缓冲区以完成队列中的所有运动，以便按时按编程执行命令。G2/3 弧暂停流式传输以将小线段注入规划器缓冲区。如果流媒体程序并不总是提供“OK”响应，您将遇到您所描述的问题。在我们的高级流脚本中，通过跟踪发送的字符和“ok”响应的数量，同时保持 Grbl 的串行输入缓冲区满，有一些方法可以提高和强大的流性能。不过，我仍然会针对我们的流脚本进行测试，以确保它不在 Grbl 的末端。
仅供参考，Grbl 的模态操作主要是由于内存限制，但如果事情正确地流式传输到 Grbl，它不应该真正影响性能或事情的运行方式。使 Grbl 非模态仍然是可能的，因为我一直在为此寻找简单而干净的解决方案，但这不是优先事项。基本上，它将涉及必须将任何非运动 g 代码块命令存储在内存中，并在步进模块完成前一个块时执行它们。
—
直接回复此电子邮件或在 GitHub #336（评论）上查看。图片已被发件人删除。

我检查了 Zapmakers 的最新代码——仍然有 M9 的陷阱。我必须评论它以获得我需要的性能，我感觉有点糟糕，因为我是他添加它的人（不确定他是否有其他人有问题）:-) 当然，我的应用程序使用 m8 /m9 有点不寻常。是的，它“解决了”问题，但我也只是在结尾处添加了几行“什么都不为我做”的代码。

这里的代码片段来自他的 https://github.com/zapmaker/GrblHoming GrblHoming / gcode.h

类 CmdResponse
{
public:
CmdResponse(const char *buf, int c, int l) : cmd(buf), count(c), line(l)
{
waitForMe = false;
if (buf[0] == ‘M’)
{
int value = cmd.mid(1,-1).toInt();
如果（值 == 9）
waitForMe = true；
}
}
公共：
QString cmd；
整数计数；
整数线；
布尔等待我；
};

-安迪

发件人：Andy Nobbs [ mailto:andy_nobbs@yahoo.com ]
发送时间：2014 年 1 月 28 日，星期二上午 11:08
收件人：’grbl/grbl’
主题：RE：[grbl] grbl 0.9c – 在批处理一些 gcode 命令后停止工作（#336）

我搞砸了——Zapmaker 加入了“if Mx”修复，而不是“if G4”。对不起，那是从去年四月开始的，自从他们 J 之后发生了很多事情

我可以发送整个文件，但它们只是重复序列——旋转表执行短序列、旋转表等。

问题在于程序序列如何终止。我可以为其提供足够的数据以全速长时间（数小时？）执行以下操作，并且在退出之前不会失败。

以下两个示例之间的唯一区别是 G4 P0.11 有效，而 G4 P0.1 失败 – 但仅在程序退出时。需要明确的是——每个命令都按预期工作，但我无法重新控制 GRBL 我在后来的实验中发现我可以通过简单地添加一些“什么都不做”G 代码来解决这个问题（比如定位一个不存在的Z 轴）在最后一个序列之后，但在 M30 之前（参见最后一个示例）。如果使用“积极的预加载”，这只是一个问题；命令的标准加载速度要慢得多，但它可以工作。我是移除 M30 还是将它留在里面都没关系。

Zapmaker 提出的“if M7”修复只是一个快速解决问题的方法，但我不得不删除它，否则我的速度优势就消失了。就我而言，积极的预加载是要走的路。我必须查看他的最新代码，看看它是否仍然存在。如果您想知道……速度和设置延迟的能力很重要。在下面的“积极预加载”序列中，我可以在大约 30 秒内拍摄 90 张高分辨率照片（相机是限制因素）；没有预载大约需要 1.5 分钟（grbl 限制）。将其乘以数千个序列，然后……

为了清楚起见，我在伪造一个旋转轴

这每次都有效（grbl 0.8c）

G92 X0（零 X = 当前位置）
G0 X-2（后退一点以设置正向间隙）

G0 X0（从这里开始）
G4 P0.11（宝石稳定延迟）
M8（快门释放-开启，使用冷却液控制）
G4 P0.12（在运动前等待图像读取，并允许快门速度）
M9（快门释放 – 关闭）

G0 X4（下一个位置（4 毫米/英寸 = 度）
G4 P0.11
M8
G4 P0.12
M9

G0 X8
G4 P0.11
M8
G4 P0.12
M9

…..
为清楚起见删除了代码通过将 X 增加 4 – “度”步骤重复序列。
……

G0 X352
G4 P0.11
M8
G4 P0.12
M9

G0 X356
G4 P0.11
M8
G4 P0.12
M9

M30（停止）

每次都在退出时失败（grbl 0.8c）：

G92 X0（零 X = 当前位置）
G0 X-2（后退一点以设置正向间隙）

G0 X0（从这里开始）
G4 P0.1（宝石稳定延迟）
M8（快门释放 – 打开，使用冷却液控制）
G4 P0.12（在运动前等待图像读取，并允许快门速度）
M9（快门释放 – 关闭）

G0 X4（下一个位置（4 毫米/英寸 = 度）
G4 P0.1
M8
G4 P0.12
M9

G0 X8
G4 P0.1
M8
G4 P0.12
M9

…..
为清楚起见删除了代码通过将 X 增加 4 – “度”步骤重复序列。
……

G0 X352
G4 P0.1
M8
G4 P0.12
M9

G0 X356
G4 P0.1
M8
G4 P0.12
M9

M30（停止）

这“修复”了退出上述“总是失败”序列的问题：
与上面的代码相同，但 4 行“什么都不做”（就我而言）。不确定我是否需要这一切，但是……
。

……

G0 X356
G4 P0.1
M8
G4 P0.12
M9

（停止前一段时间什么都不做）

G92 Y0
G0 Y10
G0 Y-10
G0 Y0

M30（停止）

发件人：Sonny Jeon [ mailto:notifications@github.com ]
发送时间：2014 年 1 月 28 日，星期二 10:09 AM
收件人：grbl/grbl
抄送：lakeside53
主题：回复：[grbl] grbl 0.9c – 在批处理一些 gcode 后停止工作命令（#336）

@lakeside53 https://github.com/lakeside53 ：请发布您的示例代码的链接。我很好奇是什么导致了这个问题。这听起来像是流媒体客户端方面的流媒体协议问题，主要是由于可疑的“IF G4”声明。这可能意味着 Zapmaker 使用的流媒体协议可能不完全兼容。对于某些命令，如 G4 暂停或 M3/4/5 主轴控制，Grbl 必须清空其缓冲区以完成队列中的所有运动，以便按时按编程执行命令。G2/3 弧暂停流式传输以将小线段注入规划器缓冲区。如果流媒体程序并不总是提供“OK”响应，您将遇到您所描述的问题。在我们的高级流脚本中，通过跟踪发送的字符和“ok”响应的数量，同时保持 Grbl 的串行输入缓冲区满，有一些方法可以提高和强大的流性能。不过，我仍然会针对我们的流脚本进行测试，以确保它不在 Grbl 的末端。
仅供参考，Grbl 的模态操作主要是由于内存限制，但如果事情正确地流式传输到 Grbl，它不应该真正影响性能或事情的运行方式。使 Grbl 非模态仍然是可能的，因为我一直在为此寻找简单而干净的解决方案，但这不是优先事项。基本上，它将涉及必须将任何非运动 g 代码块命令存储在内存中，并在步进模块完成前一个块时执行它们。
—
直接回复此电子邮件或在 GitHub #336（评论）上查看。图片已被发件人删除。

@chamnit我用的是0.9c。看来我正在使用G54。
这是（部分）我正在使用的代码。
它是由pycam生成的。

G80
G54
G90
G21
F200.00000
S1000.00000
T1 M6
G0 Z25.00 <-- It stops after this command
 X181.11 Y11.55
G1 Z0.00
 X195.60 Y14.29
 X210.89 Y18.89
...

…不幸的是，即使在移除 G54 线后，它也会停在同一点。

@robertnino: 感谢您的错误报告。你能告诉我在这个命令之后它停止是什么意思吗？它会移动到 Z25.0 并停止吗？状态报告告诉您 Grbl 处于什么状态（即 IDLE、QUEUE、CYCLE）？

只是为了确保，这是否发生在主 v0.8c 上，您是否尝试过使用不同的流媒体程序，如 UGS？（并且，请注意前面的 M6 命令不支持将

@lakeside53：从您的意思来看，听起来 ZapMaker 中的某些东西导致 Arduino 断开连接，这可能会导致您在程序结束时出现锁定问题，而其他任何地方都没有。我记得当我使用我们提供的 Python 流式处理代码时，如果我在流式传输完成后立即终止连接，但程序仍在其缓冲区中运行，Grbl 将几乎完全像您所说的那样停止。我一直不明白为什么会发生这种情况。当我将 Python 串行驱动程序更新到较新版本时，这个问题在没有我的干预下神奇地消失了。

我怀疑在您的计算机/操作系统或 Zapmaker 程序上使用的流串行驱动程序的断开协议中的某些东西会导致电压尖峰或发送某种锁定的输入。似乎当您将 Mx 条件添加到 Zapmaker 时，它会强制缓冲区完成并干净地退出。我认为当您在 G4 命令中添加十进制时，它可能只是延迟处理，使其在与断开信号锁定之前完成。

不知道如何验证这一点..可能会更改 Mx 条件以寻找 M30，所以当它到达程序结束时，它会在断开连接之前等待“确定”。或者，如果您可以在 Zapmaker 程序中添加一些内容以等待剩余的“oks”，然后再断开连接也可以。

顺便说一句，您对 Grbl 的使用非常有趣。从来没想过有人会用这种方式。:)

已经能够实现更多的硬件更改并运行更多的测试。没有尝试过不同的流媒体程序。但UGS似乎是值得信赖的。我似乎有两个不同的问题。1.) 每 25-35 分钟触发一次的限位开关和 2.) GRBL 定期冻结，UGS 没有发出警报。文件最大为 11,000 多行。所有文件都在某个时候成功完成。再次。即使禁用限制，也会发生 GRBL 冻结。所以我不认为这些问题是相关的。但不确定。

我想知道运行 windows xp 的旧 PC 是否可能是 GRBL 冻结问题的一部分。那里有任何已知问题吗？还怀疑我的 gcode 生成器 (dxf2gcode) 在解释圆弧和圆的方式上产生了一些问题。

让一个 EE 朋友在我的机器上放了一个内窥镜。他注意到没有噪音问题。注意到我的主轴非常无噪音。空切时使用 Scoped 机器 5-10 分钟。开始怀疑尖峰是否源自机器外部。例如 HVAC 的启动和关闭。

我的系统示意图位于此处：http ://www.shapeoko.com/forum/viewtopic.php?f=5&t=1268&p=19246#p19246

我有理由确定问题不在于每次都需要像 Zapmaker 那样等待 M9，而在于 M9 与退出时的程序完成有关（我可以删除 M30，这没有区别）。通过在最后一个序列之后和 M30 之前添加“什么都不做”代码的短序列，问题就消失了，所以就像需要一些延迟或其他什么。我会将此线程复制到 Zapmaker 以查看他是否有任何意见。对于大多数用户在 M9 之后等待“ok”（基本上杀死了激进的加载）是没有问题的，但对我来说，因为 M8/M9 的广泛使用，它是。在 M30 之后寻找“ok”是一个有趣的想法。

我倾向于打折电压尖峰理论。这个问题在许多计算机上是 100% 可重复的。如果它失败了-它总是失败。

感谢您考虑这个问题。

安迪

发件人：Sonny Jeon [ mailto:notifications@github.com ]
发送时间：2014 年 1 月 29 日，星期三 12:25 PM
收件人：grbl/grbl
抄送：lakeside53
主题：回复：[grbl] grbl 0.9c – 在批处理一些 gcode 后停止工作命令（#336）

@lakeside53 https://github.com/lakeside53 ：从您的意思来看，ZapMaker 中的某些东西几乎会导致 Arduino 断开连接，这可能会导致您在程序结束时出现锁定问题，而其他任何地方都没有。我记得当我使用我们提供的 Python 流式代码时，如果我在流式传输完成后立即终止连接，但程序仍在通过其缓冲区运行，Grbl 将几乎像您所说的那样停止。我一直不明白为什么会发生这种情况。当我将 Python 串行驱动程序更新到较新版本时，这个问题在没有我的干预下神奇地消失了。
我怀疑在您的计算机/操作系统或 Zapmaker 程序上使用的流串行驱动程序的断开协议中的某些东西会导致电压尖峰或发送某种锁定的输入。似乎当您将 Mx 条件添加到 Zapmaker 时，它会强制缓冲区完成并干净地退出。我认为当您在 G4 命令中添加小数时，它可能只是延迟处理，使其在锁定断开信号之前完成。
不知道如何验证这一点..可能会更改 Mx 条件以寻找 M30，因此当它到达程序结束时，它会在断开连接之前等待“确定”。或者，如果您可以在 Zapmaker 程序中添加一些内容以等待剩余的“oks”，然后再断开连接也可以。
顺便说一句，您对 Grbl 的使用非常有趣。从来没想过有人会用这种方式。:)
—
直接回复此电子邮件或在 GitHub #336（评论）上查看。图片已被发件人删除。

@lakeside53: 我认为我们在同一件事上达成一致。在节目流结束之前等待“确定”是一个问题。有一组特定的命令等待规划器缓冲区清空，然后再执行它并发送“ok”响应，以便流式传输可以恢复。M8/9 就是其中之一。这种与 Zapmaker 的流代码处理程序结束方式有关的延迟可能会导致问题。

我这样说是因为，今天早些时候，我查看了 Zapmaker 流代码。我没有机会阅读所有内容，但“激进”流媒体的工作方式看起来很奇怪。它似乎发送了一个恒定的字符流，只有 10 毫秒的延迟来控制它发送它们的速度。它看起来真的很奇怪，而且它不是预加载 Grbl 串行缓冲区的推荐方法。在 Grbl repo 的 stream.py 文件中有一个关于如何做到这一点的大纲。

老实说，我不知道在哪里可以诊断 Grbl 固件中的这个问题。没有任何突出的东西会导致我能想到或遇到的这个问题。这就是为什么这使我相信它的外部。如果确实有几台不同的机器、操作系统和流媒体程序（Zapmaker 除外）都有这个问题，那么另一种可能性可能是 Atmega8U2 芯片，它控制 USB 到串行数据流，导致 Arduino 上的某种芯片复位当数据流停止时。我想检查这一点的一种方法是在程序结束时保持串行连接短暂打开，并在延迟后关闭它。

@Mgilbride: 我想 HVAC 可能是冻结问题的根源。奇怪的事情，但这个奇怪的，被发现是电噪声问题的原因。像这样的问题很难诊断，所以我建议严格的排除过程。如果您还没有，请尝试我们的 repo 中的 Python stream.py。这是一个最小的流媒体程序，没有额外的代码可能会把事情搞砸。确保您的 XP 计算机的能源设置已关闭，我相信您已经尝试过了。断开 Arduino 的所有接线，除了步进控制线，以排除任何接线影响它。除此之外，我没有最起雾的。这里的用户（包括我自己）已经成功地在 Grbl v0.8c 上运行长时间作业并且没有遇到问题。让我了解您的最新进展，也许我们可以查明是什么’

@chamnit我没有使用流媒体程序。只需picocom并将其复制/粘贴到控制台中。
grbl在那之后不解析任何其他命令……这意味着它转到Z=25.0并在此之后停止执行。
我认为它仍处于QUEUE状态……但我不确定。我回家后会检查一下。

我将再次尝试使用 master 分支并回复您。

@robertnino: 啊，那是你的问题。您不能简单地将代码剪切并粘贴到终端程序中。如果你能这样做就好了，但我们不能这样做的原因有很多。当您粘贴程序时，Arduino 串行缓冲区会填满并在溢出时丢弃多余的字符。您必须在我们的 repo 中使用诸如 Universal G-code Sender 或我们的 stream.py Python 脚本之类的流程序。

@chamnit我正在使用流媒体程序。控制台中的剪切和粘贴只是为了测试。
我使用stream.py脚本测试了流式传输。它停在了同一点。
我可以确认它挂起的状态是Queue。
需要说明的是，上述所有测试都是使用 0.9c 版本和 Arduino Mega 完成的。

我不能使用 v0.8c……它不支持开箱即用的 Arduino Mega，尽管我找到了一个支持 Arduino Mega 并添加了第四轴“C”的 grbl 分支。它是 0.81 版……或者至少这是源中存在的版本字符串和 grbl 报告的版本字符串。
https://github.com/openpnp/grbl

对于这个版本，在控制台中剪切和粘贴我一直用于这个问题的几行 GCode（粘贴在上面的消息之一中）就可以了。我看到轴在移动，最终位置是 GCode 命令中指定的位置。

感谢您的耐心等待。

@robertnino: 好的，谢谢你的澄清。请记住，Grbl 并未正式支持 Arduino Mega。目前它是用户支持的，这意味着它可能存在一些尚未解决的问题。但是，由于内存空间的扩展，我计划最终支持它并扩展 Grbl 的功能。

此外，v0.9c 目前处于高度开发阶段，并进行了许多重大更改和改进，所以请耐心等待我处理这些错误。

@chamnit我知道这是一个开发版本。:) 我只是想帮忙。
如果有什么我可以帮忙的，请说出来！
这里有很多耐心:)

你做得很好！

好消息。电子设备的实施似乎确实是我所经历的问题的罪魁祸首。很多变化似乎已经解决了我的问题。希望长期测试/使用将证明这一点。仅在好奇的情况下阅读…

所做的更改：

1.) 增加了两端带有铁氧体扼流圈的屏蔽 USB 电缆。
2.) 重新布线电子设备。主要修改了我的 DC 0V 线路的星形图案，以更严格地遵守星形接地图案。我有一个星形接地，但允许将一些线路以菊花链形式连接起来。还将驱动板的电源分配修改为星形模式。将我的一组串联 12V PC 风扇拉入星形接地和配电。将 0.1 uf 上限从限位开关上移到 Arduino 旁边。还将下拉电阻从 1K 更改为 330 欧姆。我的 echain 中的信号线和电机线通过拉链将它们绑在 2 英寸宽轨道的相对两侧，从而实现物理分离。重新布置沿我的 X 轴运行的电机和信号线，以更好地保护信号线。将信号线从通向控制箱的电机线拆开。一团糟！
3.) 这些更改之后是连续运行相同的程序（11,000 + 行）5 次以完成。打开归位和限位开关。所有测试都通过了。没有冻结。没有虚假的极限行程。
4.) 注意到如果我在机器运行时乱搞机器，我可能会触发警报。如果我触摸框架或步进电机，限制可能会跳闸。为基础结构、X 轴和 Z 轴增加了机架接地。然而，这也突出了机器的每个轴都被其 delrin 轮隔离的事实，以及粘合铝是一种痛苦并且可能长期不可靠的事实。此外，螺栓连接结构并不是您可以拥有的最适合接地的框架。最后，如果您不打磨阳极氧化/涂层，将框架接地很容易出现用户错误。由于铝的氧化速度非常快，因此也易于长期降解。EE朋友推荐了能钻入金属的星点锁紧垫圈。也在考虑钻孔和用未涂层的地线粘合，
5.) 无需更改软件。软件运行良好。仍然比它应该的慢一点。但我喜欢它，也喜欢它的发展方向。尝试过 Zapmaker，但表现不佳。需要更多地玩。还没有尝试过python脚本。
6.) 框架接地后再进行 2 次测试。触摸整个机器试图触发限制。什么都没有触发。应该用一块铝重复。
7.) 急切地等待稳定的 V9，这样我就可以在不损坏 Z 轴的情况下更快地切割！！我要找一个程序员，这样我就可以做一些 V9 测试了。

再次，非常感谢。惊人的，启用的东西！

你能分享你的设计甚至项目的图像/pdf吗？谢谢你

No dia sábado, 8 de Fevereiro de 2014, Mgilbride notifications@github.com
escreveu：

好消息。电子设备的实施似乎确实是
我所经历的问题的罪魁祸首。很多变化似乎
已经解决了我的问题。希望长期测试/使用将证明
这一点。仅在好奇的情况下阅读…

所做的更改：

1.) 增加了两端带有铁氧体扼流圈的屏蔽 USB 电缆。
2.) 重新布线电子设备。主要修改了我的 DC 0V
线路的星形图案，以更严格地遵守星形接地图案。我有一个星形
接地，但允许将一些线路以菊花链形式连接起来。
还将驱动板的电源分配修改为星形模式。将我的一组
串联 12V PC 风扇拉入星形接地和配电。将 0.1 uf 上限从限位开关上移到 Arduino
旁边。
还将下拉电阻从 1K 更改为 330 欧姆。
我的 echain 中的信号线和电机线通过拉链将
它们绑在 2 英寸宽轨道的相对两侧，从而实现物理分离。重新路由电机和
信号线沿我的 X 轴延伸，以更好地保护信号线。
将信号线从通向控制箱的电机线拆开。
一团糟！
3.) 这些更改之后是连续运行相同的程序（11,000 +
行）5 次以完成。
打开归位和限位开关。所有测试都通过了。没有冻结。没有虚假的极限行程。 4.) 注意到如果我在机器运行时
乱搞机器，我可能会触发警报。
如果我触摸框架或步进电机，
限制可能会跳闸。
为基础结构、X轴和 Z 轴增加了机架接地。然而，这也凸显了一个事实，即每个
机器的轴被它的 delrin 轮子隔离，而且
粘合铝是一种痛苦并且可能长期不可靠的事实。此外，
螺栓连接结构并不是您
可以拥有的最适合接地的框架。
最后，如果您不打磨阳极氧化/涂层，将框架接地很容易出现用户错误。
由于铝的氧化速度非常快，因此也易于长期降解。EE朋友推荐了
能钻入金属的星点锁紧垫圈。也正在考虑钻孔和
用无涂层的自攻螺钉和喷射
导电油脂粘合接地线，以帮助粘合并防止铝
腐蚀。
5.) 无需更改软件。软件运行良好。
仍然比它应该的慢一点。但我喜欢它，也喜欢它的发展方向。尝试过 Zapmaker
，但表现不佳。需要更多地玩。还没有尝试过
python脚本。
6.) 框架接地后再进行 2 次测试。触摸整个机器
试图触发限制。什么都没有触发。应该用一块
铝重复。
7.) 急切地等待 V9，这样我就可以在不损坏 Z 轴的情况下更快地切割！！

再次，非常感谢。惊人的，启用的东西！

直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/336 #issuecomment-34525695
。

刚刚发布到QUERY：Grbl 的用途是什么？第332章

2014 年 2 月 7 日星期五晚上 9:31，José Xavier notifications@github.com写道：

你能分享你的设计甚至项目的图像/pdf吗？谢谢你

No dia sábado, 8 de Fevereiro de 2014, Mgilbride notifications@github.com

代管：

好消息。电子设备的实施似乎确实是
我所经历的问题的罪魁祸首。很多变化似乎
已经解决了我的问题。希望长期测试/使用将证明
这一点。仅在好奇的情况下阅读…

所做的更改：

1.) 增加了两端带有铁氧体扼流圈的屏蔽 USB 电缆。
2.) 重新布线电子设备。主要修改了我的 DC 0V
线路的星形图案，以更严格地遵守星形接地图案。我有一个星形
接地，但允许将一些线路以菊花链形式连接起来。还将 驱动板的电源分配
修改为星形模式。
将我的一组串联 12V PC 风扇拉
入
星形接地和配电。将 0.1 uf 上限从限位开关上移到 Arduino
旁边。
还将下拉电阻从 1K 更改为 330 欧姆。
通过拉链在我的拖链中物理分离信号线和电机
线
将它们放在 2 英寸宽轨道的两侧。
重新布置沿我的 X 轴运行的电机和信号线，以更好地保护信号线。
将信号线从通向控制
箱的电机线拆开。
一团糟！
3.) 这些更改之后是连续运行相同的程序（11,000 +
行）5 次以完成。
打开归位和限位开关。所有测试都通过了。没有冻结。没有虚假的极限行程。 4.) 注意到如果我在机器运行时
乱搞机器，我可能会触发警报。
如果我触摸框架或步进电机
，
限制可能会跳闸。为基础结构增加了机架接地，X
轴和z轴。然而，这也突出了机器的每个
轴都被其 delrin 轮隔离的事实，以及
粘合铝是一种痛苦并且可能长期不可靠的事实。
此外，
螺栓连接结构并不是您
可以拥有的最适合接地的框架。
最后，如果您
不打磨阳极氧化/涂层，将框架接地很容易出现用户错误。 由于铝的氧化速度非常快，因此也易于长期
降解。
EE朋友推荐了能钻入金属的星点
锁紧
垫圈。也在考虑用无涂层的自攻螺钉和水枪钻孔和
接合地线
导电油脂，以帮助粘合并防止铝
腐蚀。
5.) 无需更改软件。软件运行良好。仍然 比它应该的
慢一点。
但我喜欢它，也喜欢它的发展方向。尝试过
Zapmaker
，但表现不佳。需要更多地玩。还没有尝试过
python脚本。
6.) 框架接地后再进行 2 次测试。触摸整个机器
试图触发限制。什么都没有触发。应该用一块 铝重复
。 7.) 急切地等待 V9，这样我就可以在不损坏 Z 轴的情况下更快地切割！！

再次，非常感谢。惊人的，启用的东西！

直接回复此邮件或在 GitHub 上查看<
https://github.com/grbl/grbl/issues/336#issuecomment-34525695&gt;
。

直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/336 #issuecomment-34526239
。

好吧……说得太早了。运行实际作业时再次收到警报。真是令人沮丧。在软件中禁用了限制和归位，仍然可以得到它们！任何可能引起警报的事情的澄清。包括何时禁用硬限制？

回到断开所有东西与电路板的连接并对其进行测试。

@Mgilbride: 哎呀！很抱歉听到这个。要回答您的问题，可以引起警报的地方并不多：显然是硬限制；活动周期期间的软复位，可由用户发送 Ctrl-X 字符或 A0 上的软复位引脚变为低电平触发；或者，如果您使用的是带有软限制的 Grbl 版本，则可能会因超出轴的最大行程范围而引发警报。

我想我们没有解决的一件事是询问您是否将物理按钮连接到 A0、A1 和 A2 引脚。如果你这样做，这可能是你问题的根源。它们的工作方式与硬限位引脚非常相似，需要小心接线和屏蔽。回头看看你在 CNC 机器上的帖子，看起来你确实连接了开关。如果您还没有尝试删除它，请尝试删除它，看看这是否会有所改善。

作业因“发送状态命令时出现 IOException：writeByte 中的输入/输出错误”而中断。这个错误出现在 UGS 控制台中。听起来像是 USB 连接丢失？

是的。我在 A0、A1 和 A2 上连接了开关。它们没有被屏蔽。除了最后一次运行的限位开关之外，我还拉了那些。

@Mgilbride： 是的。这可能意味着 USB 连接丢失。我一直在关注你关于 UGS 问题主题的帖子，看来 Will Winder 同意你的观点。这可能是您的计算机正在馈送 Grbl 或工具运行时出现的一些接地问题，Will 提到他的 Dremel 会导致相同类型的问题。只是为了消除刀具，您可以在不打开主轴的情况下对刀具路径进行空运行吗？

看起来这是一个侥幸。（十指交叉）这种事只发生
过一次。主轴是全新的，所以我不会轻易怀疑那个组件。
本周早些时候切割泡沫几个小时，没有进一步的事故。只需
确保 USB 尽可能远离任何噪声源。我觉得我
有点粗心，因为我有一条新的屏蔽电缆，并且一直在做很多
修改和测试。电子设备上的一切都运行良好，
只连接了步进信号线。现在
要一次添加一个轴的限制，看看会发生什么。我
想我得再多一点耐心来帮助解决这些细节
。

我在关闭主轴的情况下做了很多测试。实际上似乎从来没有成为
麻烦的根源。

2014 年 2 月 12 日星期三上午 11:15，Sonny Jeon notification@github.com写道：

@Mgilbride https://github.com/Mgilbride：是的。这可能意味着 USB 连接丢失
。我一直在关注你关于 UGS 问题主题的帖子，
看来 Will Winder 同意你的观点。这可能是
您的计算机正在馈送 Grbl 或工具
运行时出现的一些接地问题，Will 提到他的 Dremel 会导致相同类型的
问题。
只是为了消除刀具，您可以在不打开主轴的情况下对刀具路径进行空运行吗？

直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/336 #issuecomment-34884496
。

@Mgilbride： 伟大的！我希望事情是侥幸。让我们知道您的进展。

我现在遇到了这个问题，就像一开始就做的那样，但是你是怎么解决的我不明白，你能不能简单地用几个步骤来解决它。我已经在其他计算机上尝试了我的 arduino，它工作正常 – 所以问题出在我的笔记本电脑设置上。也许关闭报告消息？但如何？
谢谢阿特姆
_