评论
为了以防万一,我经常在重启时或重启后的第一个命令上看到乱码。 请参阅此通过 fluidterm 连接的示例:
……以及这个通过 gSender 连接的例子:
来自 gSender 的另一个例子:
(那是我在连接、发布 |
I2S_STREAM 模式在过去引起了一些问题。I2S_STATIC 似乎更可靠。 |
问题发生的频率如何?大多数时候,还是很少?不经常发生的问题可能很难调试。 |
我很高兴尝试切换到 I2S_STATIC。
它恰好发生了两次。这正是我在此控制器上运行长(>100 行)程序的两次。 在接下来的几个小时内没有任何进一步的回复我会尝试:
|
我在黑暗中使用 I2S_STREAM 与 I2S_STATIC 进行拍摄。我需要一个可重现的测试用例来解决这个问题。我暂时没有什么好主意。 |
Root Controller 看起来像一个不错的硬件,但由于我没有可以玩的东西,所以深度调试并不容易。I2S_STATIC 似乎不太容易触发移位寄存器链上的信号完整性问题,但这也是猜测。我们有一些关于 MKS Tinybee 问题的报告,这些问题在您切换到 I2S_STATIC 时得到解决。信号完整性是我的猜测,但我也没有 Tinybee,所以我无法证明这一点。我现在对各种不同的板感到疯狂,它们似乎都有不同的奇怪故障。 |
它是可重复的,尽管这次它没有发生在完全相同的地方。 与上次潜水相同的程序,但这次从 WebUI/SD 卡运行,步进/引擎切换到 I2S_STATIC。它再次潜入桌面,但这次是在上次触发它的大行程移动之前一点。WebUI 控制台输出 其他想法: 嗯……我不知道还有什么要检查的。 |
刚刚发生第四次暴跌,我的猜测是 fluidnc 没有责任,但我非常感谢你的意见,@MitchBradley(或其他任何人)。 这次我没有按 E-stop。我用身体抓住了 Z 轴(通过防尘套……“安全地”),我相信它没有动力并且在自身重量的作用下掉落。然后我通过 VFD 控制面板停止了主轴,然后点击控制>feed_hold_pin 按钮(但我很确定 Z 步进器仍然没有动力)。大概 30 秒后,一切都没有动,Z 轴步进器的保持扭矩已经恢复(不确定何时在那个窗口中)。我检查了其他步进器,它们也通电并保持不动。 所以,新理论(这是一个糟糕的理论,但这是我拥有的最好的理论): 自上次运行以来我改变的事情:
(我仍然通过 WebUI 从 SD 运行,没有连接 gSender 或其他发件人。) 使用此设置,它成功运行了一个 30 分钟的程序,我手动将其分成两部分,而不是通过 56 分钟的程序失败了 85.43%。(在我看来,这个证据似乎支持过热理论——我在坠机前坚持了更长时间,因为任何过热的东西都有更多的时间冷却,并且在门打开时更好的对流。) 可能相关的机器规格详细信息: 外壳 1: 外壳 2: |
现在关闭这个问题,因为我最好的理论表明这不是一个 fluidnc 问题。 但如果有人有任何建议,我将非常感激听到他们! |
控制板
根控制器
董事会供应商的帮助
机器描述
Openbuilds / Maker Store Lead CNC V3(高阻模组)
输入电路
没有反应
配置文件
启动消息
用户界面软件
发件人
发生了什么?
在长
G0
行程移动过程中,机器两次陷入工件。最近在以下 GCODE 中,来自较长文件的第 24881 行(完整文件可用):
……所有这些都运行良好,然后:
从上面的行来看,它仍然处于
G0
模态,这是一个很长的移动到表格的前端。在大约 470 的 Y 值处,这大约是行程移动的三分之一,在我按下急停按钮之前,它至少下降到 Z-30。紧随本节之后的 GCODE,以防有帮助:
上一次发生这种情况也是在一次长途
G0
旅行中。它直接向下坠落,远到足以让夹头撞击工件,然后它拖过一个 L 形移动,这可能是它执行了应该在行程移动之后进行的移动。其他信息
我已经毫无问题地运行了几个短程序。
Z轴牢固不打滑。它是向下行驶,而不是滑倒。 我可以为该程序提供 gcode,但可以从中收集到一个快速摘要:
不幸的是,我一直无法检查机器状态,因为我两次都按下了急停按钮,控制器就关闭了。
我已经在 Root CNC Discord 上描述了这些问题。他们是一个非常乐于助人的团体,但没有想法并建议我来这里。
任何帮助是极大的赞赏。
与此同时,我将尝试通过 WebUI 上传未来的程序,以切断与图片发送者的任何通信。