评论
|
这么晚才回复很抱歉。您是否看到控制台小部件报告的任何错误?如果您使用 NPM 安装了 cncjs,则可以运行 如果您有录制的视频,将有助于排除故障。 |
|
它也发生在我身上。我认为这是我的设置中的某种问题(EMI?),但也许事实并非如此。 |
|
这个问题可能类似于#186(评论) 当查询解析器状态 ($G) 时,它会在 1.9.x 上发生。如果查询计时器在响应 10 秒后超时,解析器状态查询将再次发送到 Grbl,因此它将在一段时间后消耗 Grbl 上所有可用的接收缓冲区。当降低运动命令的进给率时,这将很容易重现,例如 https://github.com/cncjs/cncjs/blob/master/src/app/controllers/Grbl/GrblController.js#L465-L479 const queryParserState = _.throttle(() => {
const now = new Date().getTime();
const lastQueryTime = this.actionTime.queryParserState;
if (lastQueryTime > 0) {
const timespan = Math.abs(now - lastQueryTime);
const toleranceTime = 10000; // 10 seconds
// Check if it has not been updated for a long time
if (timespan >= toleranceTime) {
log.debug(`Continue parser state query: timespan=${timespan}ms`);
this.actionMask.queryParserState.state = false;
this.actionMask.queryParserState.reply = false;
}
}
// : : :
}
我应该已经知道这个问题的根本原因在哪里。问题解决后,我会通知您。 |
|
Cheton,GRBL BLOCK_BUFFER_SIZE 是 15 或 16。查看您的代码,我看到您使用 8 个字节来避免缓冲区溢出,并使用 5 秒重试发送…. 您如何看待更改块大小(15 或 16 — 取决于规划器块大小)并使用更多时间(大约 30 秒),因为某些命令(即 F35)使用大量时间来完成。 可能这不是错误的根本原因,因为检查接收缓冲区何时有发送槽很重要,但有助于减少错误。不? |
|
扣除 8 个字节用于确定在使用字符计数流协议时发送方使用的可用缓冲区大小,它与 Grbl 的 BLOCK_BUFFER_SIZE 无关。你可以在#186(评论)看到我的评论 |


您好,我遇到了一个问题,即作业的第一次运行搞砸了各种 gcode,无法进入机器。我在功能相对强大的 i5 笔记本电脑上以 115200 波特率使用基于 arduino 的 GRBL 板。此问题发生在多台计算机上。cncjs 版本 1.9.6
缺少的 gcode 会导致不稳定的行为,例如钻头在初始插入时不会向下移动到工件。再次运行作业正常。
有没有人发生过这种情况?