看起来命令簿记有问题，我添加了此检查以防止一次意外启动多个流或在流中间发送手动命令。

如果您注释掉AbstractController.java中第 358 行的检查，您可以解决该问题，直到我可以花一些时间找出问题所在。

谢谢您的帮助。我真的不知道我的代码处理方式，所以我可能不得不
坐一会儿，但我只是想确保有人
知道我的问题/其他人是否有同样的问题。

再次感谢！

2013 年 7 月 12 日星期五，Will Winder 写道：

看起来命令簿记有问题，我添加了此
检查以防止一次意外启动多个流或
在流中间发送手动命令。

如果您注释掉 AbstractController.java 中第 358 行的检查 https://github.com/winder/Universal-G-Code-Sender/blob/master/src/com/willwinder/universalgcodesender/AbstractController.java#L358 您可以解决问题，直到我可以花一些时间找出
问题所在。

—
直接回复此电子邮件或在 GitHub 上查看它 https://github.com/ /issues/81 #issuecomment-20877184
。

软重置不会清除 AbstractController.IsReadyToStreamFile() 检查的缓冲区。屏幕截图中的消息来自 waitingResponseQueue 或 outgoingQueue 仍然包含命令时抛出的异常。我犹豫是否提出修复/拉取请求，而不考虑它们如何与 completedCommandQueue 和 errorCommandList 交互，并且知道发出软重置时所需的结果是什么。即调用 flushSendQueues() 来清除所有内容，或者保持 completedCommandQueue 完好无损？prepQueue 在这种情况下？

@michmerr软重置可能会刷新这些队列。对于 rawkstar320 报告的原始问题，这可能是一个很好的解决方法。过去，我遇到过一些问题，无法让软重置按预期工作，而且从来没有抽出时间尝试过。

拉取请求#102将在软重置时刷新缓冲区。我还没有看过其他让队列处于阻塞状态的场景。

“我添加了这项检查以防止一次意外启动多个流或在流中间发送手动命令。”

您目前在流式传输期间阻止手动命令和机器控制。但是，您确实希望在流式传输时能够发出的命令很少。比如你说的软复位。特别是在保持命令之后。

@winder的6687ab7提交允许作业正确完成，队列处于良好状态以供继续使用。命令列表中的簿记不同步，因为流式传输期间的更新假定命令列表在开始时为空。流式传输之前该视图中的任何命令都会影响在流式传输期间选中哪些框。不过，幕后的队列很好。

我将包括对表更新内容的修复以及我的模拟器驱动的时间估计更改。

快速工作。期待尝试。谢谢。

在 2014 年 2 月 14 日星期五晚上 7:33，michmerr notifications@github.com写道：

@winder https://github.com/winder的 6687ab7 6687ab74bb1b153aa7748f4a5ad73fa6e4c201d6commit允许作业正确完成，队列状态良好
，可以继续使用。命令列表中的簿记不同步
，因为流式传输期间的更新假定命令列表在
开始时为空。流式传输之前该视图中的任何命令都会影响
在流式传输期间选中哪些框。不过，幕后的队列
很好。

我将包括对表更新内容的修复以及我的
模拟器驱动的时间估计更改。

直接回复此电子邮件或在 GitHub 上查看它 https://github.com/ /issues/81 #issuecomment-35141960
。

我也收到此错误。我在 Shapeoko v2 上使用 UGS 1.07 和 GRBL 0.9f。我还有一个问题，即 UGS 并不总是确认工作已完成。我并不总是在最后弹出一个窗口，说明这项工作花了多长时间。然后，我必须先按 UGS 中的取消按钮，然后才能执行任何操作。请注意，我没有在代码末尾使用 M30 命令，因为它会将 GRBL 重置为英寸并清除工作坐标。也许最后没有此命令是我的问题，我打算做一些测试。