评论
.png "使用 smoothieware 进行铣削会导致命令提交在一段时间后停止 #1091"){kind=avatar}
|
这在某些旧版本中有效吗？你能试试吗，例如。0.9.11 发布，所以我可以跟踪是否有任何更改？ 问题是我没有任何能够运行冰沙的电路板来调试它。如果有人可以为我调试这个，我会非常高兴？所有相关代码现在都应该在 我猜解析存在一些问题，其中 float() 得到“40.010”。而不是“40.010”。不知道。 如果有人有冰沙和 python 知识。你能看看 SMOOTHIE.py 的以下部分吗？ def parseBracketAngle(self, line, cline):
# <Idle|MPos:68.9980,-49.9240,40.0000,12.3456|WPos:68.9980,-49.9240,40.0000|F:12345.12|S:1.2>
ln= line[1:-1] # strip off < .. >
# split fields
l= ln.split('|')
# strip off status
CNC.vars["state"]= l[0]
# strip of rest into a dict of name: [values,...,]
d= { a: [float(y) for y in b.split(',')] for a, b in [x.split(':') for x in l[1:]] }
CNC.vars["mx"] = float(d['MPos'][0])
CNC.vars["my"] = float(d['MPos'][1])
CNC.vars["mz"] = float(d['MPos'][2])
CNC.vars["wx"] = float(d['WPos'][0])
CNC.vars["wy"] = float(d['WPos'][1])
CNC.vars["wz"] = float(d['WPos'][2])
CNC.vars["wcox"] = CNC.vars["mx"] - CNC.vars["wx"]
CNC.vars["wcoy"] = CNC.vars["my"] - CNC.vars["wy"]
CNC.vars["wcoz"] = CNC.vars["mz"] - CNC.vars["wz"]
if 'F' in d:
CNC.vars["curfeed"] = float(d['F'][0])
self.master._posUpdate = True
|
.jpg "使用 smoothieware 进行铣削会导致命令提交在一段时间后停止 #1091"){kind=avatar}
|
我刚刚开始弄乱这些东西，所以我从未尝试过任何早期版本。 我会试一试 0.9.11，看看我是否可以在源代码中四处寻找（虽然我不是特别擅长 Python） 顺便说一句，我尝试了拦截，bCNC 拒绝连接到端口（我认为是非法操作——不幸的是现在我不能尝试检查，但我稍后会做出适当的报告） |
/dev 中那个 tty 的权限可能有问题 我发现你可以像那样调试串行而不会被拦截。把它放到 bCNC 中的端口输入：
（bCNC 必须在控制台中运行） |
我从来都不是蟒蛇人。但后来我开始调整 bCNC，所以现在我可以将 python 添加到我的 CV 哈哈 |
|
好吧，我想我开始有了主意。我现在从 git 检出的源代码树运行，78aa077 到目前为止没有解析错误，但它仍然停止了。这里： 一旦状态开始返回 Idle，事情就会卡住。这是该会话的完整间谍日志，包括初始连接、归位、慢跑和整个作业直到失败： 我也完全成功地运行了一次（文件与上面的文件略有不同）。这是最后发生的事情。这是命令窗口的最底部： 这正是文件末尾的内容，非常好。但是，bCNC 仍然认为工作还没有结束。缓冲区窗口包含： 所以这是我的看法：使用 Smoothie，至少在某些情况下 Smoothie 没有确认命令，或者 bCNC 错过了确认。然后在工作中间的某个随机点，bCNC 正在等待更多的确认，而 Smoothie 正在等待更多的工作，没有任何事情发生。 待解决的问题：
|
|
这与#1100有关吗？ |
|
是的，事实上#1100可能是整个问题。当我发现特定的东西坏了时，我只是开票，以避免在同一个问题编号下有一堆不同的东西。 到目前为止，新固件运行良好，但上面的 bCNC.log 并没有完全按照我的预期运行。它中断的部分是： 如果一切都与缓冲有关，那么以这种方式停止似乎很奇怪。3 个“ok”肯定释放了缓冲区中的空间，这至少为另一个命令腾出了空间。因此，G3 得到确认，必须再次离开空房间，然后事情应该继续进行，但事实并非如此。 所以我怀疑另一个问题仍然存在： 那个“？ok”可能被解析错误，并且不算作确认。 到目前为止只是一个猜测，但它可以解释为什么事情在这一点上停滞不前。 |
|
日志不符合您的期望是否仍然存在一些实际问题？ 我知道发件人代码现在一团糟。我已经开始稍微理清代码了……但这需要一些时间……换句话说：如果您有时间清理主要的发件人，我会很乐意提取您的更改。我没有时间做这个。因此，除非这会导致问题，否则恐怕我无能为力。 现在我所有的努力都是为了发布稳定的 bCNC。不优雅也不干净。但至少与上一个版本一样稳定和实用。 |
|
不，我的意思是查看我失败的工作日志，它在一个意想不到的点停止了，甚至考虑了 $G 的事情。 我的期望是，由于缺少确认，该工作应该停留在 $G。 例如：
到那时，如果缓冲区已满，它将永远等待。但这不是我的工作失败的原因： 但是请注意它不是那样的。它发出 G3，得到确认，然后挂起。这很奇怪，因为该确认应该为另一个命令腾出空间，对吧？ 所以我怀疑某处可能还有另一个问题。 |
|
但它会冻结或崩溃吗？:-) 我不确定您是否仍然遇到铣削问题，或者您只是在谈论已解决的问题。我只是想知道这个问题是否如此严重，我应该推迟 bCNC 的发布，直到这个问题得到解决。或者如果我可以安全地发布 bCNC 0.9.15 并在以后修复它。 |
|
所以我最初的问题是我生成了一个 .nc 文件，打开它，运行它，然后铣削进行到一个点，直到有时它停止。bCNC 继续运行，界面保持响应，但 bCNC 不再向机器提交任何 gcode 并在活动作业中间显示“空闲”状态。 那时我所能做的就是完全中止这项工作。没有办法恢复它。 现在 $G 问题肯定占了很大一部分，如果不是全部的话。问题是我不确定为什么即使考虑了 $G 错误，它也恰好在那个时候停止了。 所以我只是仔细查看了源代码，然后才意识到：缓冲区限制以字节为单位。如果确认释放了一个短命令占用的空间，然后必须执行一个更长的命令，那么确实有可能出现“ok”仍然不允许继续的情况。 所以在看了之后，事情对我来说更有意义了，很可能一切都在这一点上得到解决。我会说继续那个版本 |
|
行。如果你觉得有一些特殊情况它停止响应，你可以尝试对bCNC进行酷刑测试以找出如何触发它。如果您发现了什么，请告诉我们。 |
|
我已经做了一些初步测试，到目前为止结果看起来不错。 我肯定会很快做更多的测试。 |
|
好的，经过更多测试后，据我所知，一切正常。我做了两个半小时的工作，没有遇到任何麻烦，还进行了一些简单的酷刑测试。我认为这可以宣布解决。 上面的 parseBracketAngle 问题在我之前的测试中确实弹出过一次，但似乎无关。有一次它发生在连接期间，可能是由于某些不同步造成的。我将尝试改进错误处理，以便用户始终可以找出解析失败的确切原因，而无需使用 spy:/// 并从终端运行。 |
设想：
Proxxon MF70 带有运行 Smoothieware 的 Smoothieboard，使用 firmware-cnc-latest（当前最新可用，9 天前上传）
我正在 Fedora 上运行通过 git 的 pip 安装的最新代码（0.9.14，2018 年 2 月 5 日）
结果：
执行了一些动作，直到一切都停止了。终点没有被击中，没有显示警报或错误。
状态显示：Current 183 [3656]
Controller buffer fill is at 93%
状态为“空闲”
“开始”按钮保持灰色。
在我运行程序的终端上，它说：
gcode 文件在任何地方都不包含任何“40.010”。
进一步的命令提交失败。例如，我无法将 M999 发送给 Smoothie。
所以，怀疑是 smoothie 代码有问题，我尝试以 GRBL1 模式连接。这实际上效果更好。机器这次完成了椭圆，又走了一点点：
这是 gcode 窗口的结尾：
这是缓冲区：
终端包含：
其中一堆可能是我在慢跑。保留也是我的，但是是在机器停止移动相当长一段时间后才发出的。
我在 Fusion 360 中插入了一个手动工具更改，但不确定那时会发生什么（我对此还是很陌生），所以可能会出现问题。状态只是变为“空闲”，没有任何来自程序的消息。
另外，早些时候我尝试使用 Pronterface 来提交 gcode。这似乎工作得很好，但它似乎不是完成这项任务的最佳工具。
这是我发送的 gcode：
维卡.zip
所以看起来这里可能有几个问题：
谢谢！