评论
.png "看似正常的 g 代码文件上的错误 24 #242"){kind=avatar}
|
我认为每秒有太多命令需要发送： 我知道，常规 115200 波特 = 大约。每秒应该可以传输 11520 个字符… |
.png "看似正常的 g 代码文件上的错误 24 #242"){kind=avatar}
|
抱歉，“ca”是什么？？：/ 编辑：它像“大约”吗？ |
|
是的，大约。会更好-对不起。 |
|
好的，所以：为了避免缓冲区中没有命令，您必须发送足够的命令以允许以 167 毫米/秒的速度移动。在我们的例子中，这意味着每秒 55 行。但是你告诉我这不应该是我们波特率的问题？ 事实上，我们 99% 的时间都能够处理文件，这可能与该声明一致，而且我们的速度通常超过 10.000 毫米/分钟，而且它仍然有效。 请问是什么让您认为问题与此有关？ |
|
我的意思是，波特率不是问题，但可能是在控制器/grbl 内部接收和处理命令。 我不知道如何找到原因… |
错误 24 来自 GRBL 本身？这不是 grbl plotter 在遇到问题后“提出”的东西吗？
它有什么主要缺点吗？比如，我们能否一直让它一直运行，直到我们再次遇到问题，而不会产生其他问题或减慢速度？ |
|
错误 24 – 现在文本略有不同：
我不知道，你需要弄清楚。如果我记得：不建议将其保持打开状态。您需要检查所有（grbl 的）*.h 文件 |
|
关于 #define REPORT_ECHO_LINE_RECEIVED |
|
检查日志选项以将回显命令与发送的命令进行比较：https ://github.com/svenhb/GRBL-Plotter/releases |
|
好，谢谢 ！ |
再一次问好，
该过程有时会卡在文件中间：
问题似乎来自流媒体，我们出现了“错误 24”。
我能够通过玩弄“暂停/开始流式传输”和一些“恢复”来解除这个过程。
这是它发生时的日志：
日志文件.txt
这不是第一次处理这个文件，所以它似乎不是问题，但如果你需要，我可以通过邮件将文件发送给你。
感谢您的帮助。