评论
.jpg "隐形警报器 #241"){kind=avatar}
|
你好， 是的，这个问题现在非常模糊，唯一的办法就是弄清楚它是从哪里来的。我希望我们能够用这些新日志捕捉到它。 由于上次我们已经注意到“警报”似乎不是合法的，它们可能在没有错误的情况下发生，并且似乎与第 3 个串行终端有关。 |
|
当我测试新版本时，我确实遇到了这个错误！而且我在日志中间，所以这一次，我确切地知道它是如何以及何时发生的。 我正在处理一个非常常见的文件，我在一百万次之前在硬件模拟设置中（在我的办公桌上，但使用实际的电路板）。所以我首先要说的是，不是文件或机器（干扰等）导致了问题。 一切顺利，阻塞发生在文件的最后。通常 grbl-p 应该发送一个 (^3 $SH0) 命令来请求关闭激光器的快门。我注意到这个问题是因为文件看似完整但 grbl-p 并没有认为这个过程是完整的，我意识到我们错过了快门命令和过程一的结束。我按下 kill alarm 并发送了丢失的命令。 它符合我以前遇到这个问题的经验，它发生在向第三个 COM 发送命令之前，甚至还没有发送命令。这就是为什么起初它可能与第 3 系列有关并不明显。 这是日志： 文件以防万一： |
.jpg "隐形警报器 #241"){kind=avatar}
|
问题：在向第 3 个串口发送任何命令之前，第 1 个串口 (grbl) 必须为“IDLE”且缓冲区必须为空。 日志显示，缓冲区理论上不为空，并且“free”不再更改（可能是因为缺少“ok”消息）。 |
|
你好斯文，新年快乐！ |
|
新年快乐！ 我写道：我建立了一个工作区：如果“免费”没有变化，它无论如何都会发送到第三个连续剧，因为 grbl 已经是“空闲”了。 您是否尝试了最新版本 1.6.4.0？ |
|
哦对不起 ！我不认为你在 1.6.4.0 中改变了这个我还在使用 1.6.3.5。我想也许你还没有完成更改或者它还没有工作。 我会试试看，然后再回复你。 |
|
我目前正在机器上运行测试，我在一个小时内没有遇到问题，所以它在这方面看起来不错！ |
|
实际上，我认为它发生的几次是在“点”形状上，或多或少被忽略了，不是吗？ |
|
我已经尝试了几个文件，好几次了，但我没有再次清楚地注意到这个问题。也许这只是重点（无论如何我们不应该在我们的文件中有点）。 无论如何，现在让我们说问题已经解决了，如果我们能再次清楚地看到问题，我会回复你。 |
|
好的，问题在#255中提到的文件上再次反复出现。也许这两个问题是相关联的，所以我会尝试新版本，看看效果如何，但似乎有些牵强。 |
|
我收到了上次发生的视频，我们可以清楚地看到应该在页面之间发送的命令是在最后一个图完成之前发送的。这导致在移动时绘制最后一行/图形：/ |
|
任何有助于识别问题的日志文件？ |
|
我会努力得到他们 |
|
好的，我有一个。但是，很难从日志中知道问题何时发生，至少对我而言。幸运的是日志不是太长： |
|
我发现了问题： |
|
如果是那样就好了！ |
|
好像解决了 |
描述错误
你好，
我们有一个错误，第三个串行 COM 会卡住，即使重置或重新启动也无法解决问题。起初我们认为这是我们的板或其固件的问题。
经过一段时间试图找到问题后，我们意识到这只是 GRBL-plotter 的第三个终端拒绝发送命令（它仍然能够从板上接收数据）。我花了一些时间才意识到这与我们被警报阻止时的行为相同（尽管主终端显然没有卡住）。所以，凭着直觉，我按下了“Kill Alarm”键，它解除了终端的卡住。
问题是没有任何通常的信号告诉我们有警报。即使现在我们有了解决方案，它也确实不直观，每次出现问题时，操作员都会停留在问题上。
重现
不幸的是，它在各种情况下时不时发生。我们还没有找到是什么触发了这个“隐形警报”。我们甚至不确定它是否需要“警报触发情况”才能发生。
我知道这真的不理想……
我希望在您的帮助下，我们能够更准确地诊断问题。
预期行为
首先，我认为我们需要弄清楚这个“假警报”是否真的应该发生，或者它是否是一个小故障。根据这一点，我们想让它完全消失或完全可见 ^^。
预先感谢您的帮助 ！