开源改变世界!!

工作通常不会正确结束 #718

推推 grbl 2年前 (2023-01-27) 106次浏览
关闭
dmavrikakis 打开了这个问题 2017 年 8 月 27 日 · 11 条评论
关闭

工作通常不会正确结束#718

dmavrikakis 打开了这个问题 2017 年 8 月 27 日 · 11 条评论

注释

工作通常不会正确结束 #718

我经常遇到这个问题,它正在成为一个真正的痛苦。工作结束后,我发现播放和停止按钮通常处于活动状态,但其他所有按钮都显示为灰色。按下停止按钮没有任何效果,如果我断开连接并重新连接,那么一切似乎都恢复正常,只是在我关闭并重新打开 UGS 之前,慢跑窗口将保持不活动状态。我正在使用最新的每晚构建(UGS 平台),我也遇到了与稳定构建相同的问题(这就是我尝试每晚构建的原因)。我的 GRBL 是 0.9。任何帮助将不胜感激。

工作通常不会正确结束 #718

这里也是。我在过去的几个 UGS 版本中遇到了完全相同的问题。更新 GRBL 没有效果(当前运行 1.1f)。将“$$”传递到命令行似乎有帮助,但并非总是如此。我已经尝试过不同的 gcode 结尾,但这似乎没有任何效果。

工作通常不会正确结束 #718

我很高兴看到不仅仅是我有这个问题,我有点担心这可能是我机器的问题。

我注意到的唯一一件事是,尽管点动控制器处于非活动状态,但您仍然可以按下“运行”按钮,并且作业将开始,这意味着如果您正在做很多相同的作业,这还不是世界末日。

我刚刚克隆并设置了该项目,所以我将尝试在调试中运行它,看看我是否可以找到问题的根源,并会报告更多信息,希望我们能弄清楚这个问题.

工作通常不会正确结束 #718
所有者

@dmavrikakis这可能与数组AbstractController中保留了一个额外的命令有关。activeCommands

您正在发送的程序可能有一些问题导致 UGS 预处理器出现问题,这导致 UGS 期望得到它不应该得到的“ok”。你能分享一个你遇到这个问题的程序吗?

了解 GRBL 0.9 和 1.1 会发生此问题非常有帮助。目前,1.1 有更好的支持(因为大多数报告错误的人都在使用该版本),但问题似乎与 GRBL 的版本无关。

工作通常不会正确结束 #718

令人沮丧的是,在连接到我的 cnc 机器的 macbook 上进行调试时,我无法重现它。我实际使用的计算机(RPi)将使用标准构建重现它而不会失败,问题是我无法在 RPi 上轻松调试。

当我有更多时间时,我将在 AbstractController 中使用大量日志记录构建并在我的 RPi 上运行它以查看我是否可以确定卡住的原因/位置。目前我可以肯定地说的是,我经常没有收到对 fileStreamComplete 的调用,这使应用程序处于不确定状态。

我附上了一个程序,但我不认为你会在那里找到很多东西,如果是这样的话,我希望在我的 macbook 上运行它时会出现问题。

AB.txt

工作通常不会正确结束 #718

这与我在 Issue #593中报告的问题相同

#593

我第一次看到它是在 v1.0c 中,但它在 v1.1 中继续存在。

我还使用 Raspberry Pi 作为我的主要平台。

工作通常不会正确结束 #718

值得注意的是,我也在 Pi 2 上运行 UGS。

工作通常不会正确结束 #718

我也有同样的问题很久了。我试图绕过这个问题,但它不起作用。
我将 G1X0Y0F1001 添加到我的 gcode 文件的末尾。我尝试检查该命令是否完成。
它发送 G1X0Y0F1001,但在完成时有时会崩溃。实际上,不仅最后一行而且最后第三行或第二行也丢失了。发生的事情是,ugs 认为它​​仍在发送命令,因此它会保持这种状态。

@OverRide
public void commandSent(final GcodeCommand command) {
System.out.println(“commandsent:”+command.getCommandString());

java.awt.EventQueue.invokeLater(new Runnable() {
    @Override
    public void run() {
        // sent
        if (commandTableScrollPane.isEnabled()) {
            commandTable.addRow(command);
        }
        //commandTable.updateRow(command);
    }});

}

@OverRide
public void commandComplete(最终的 GcodeCommand 命令){

System.out.println("commandcomplete:"+command.getCommandString());
if(command.getCommandString().equals("G1X0Y0F1001")){
	try {
		Thread.sleep(100);
		backend.sendGcodeCommand("$$");
		Thread.sleep(100);
	} catch (Exception e) {
	}
}

// update gui
java.awt.EventQueue.invokeLater(new Runnable() {
    @Override
    public void run() {
        if (commandTableScrollPane.isEnabled()) {
            commandTable.updateRow(command);
        }
        if (backend.isSendingFile()) {
            if (vw != null) {
                vw.setCompletedCommandNumber(command.getCommandNumber());
            }
        }
    }});

}

工作通常不会正确结束 #718

@winder当您在文件流式传输期间禁用控制台时,它取消了我解决此问题的方法并迫使我关闭并启动 UGS 以继续。我做了大约 5 个小时的不同刀具路径(我会说 12 条左右的刀具路径,需要新归零的多位更改)和每三到四个文件流。它变得非常乏味,幸运的是我切换到 G54,所以我只需要重新回家并继续雕刻。

工作通常不会正确结束 #718

工作通常不会正确结束 #718
1- 有时会发生这种情况,所有文件已发送、完成并得到响应,但不知何故无法完成流。所以它像第一张图片一样卡住。

工作通常不会正确结束 #718
2- 稍后,我单击“取消”按钮。我唯一注意到的是持续时间值的变化。

工作通常不会正确结束 #718
3- 我再次点击“Cancel”按钮,这次它从“Idle”进入“Hold”状态。(见活动状态值)

工作通常不会正确结束 #718
4- 我点击“恢复”按钮,最后 UGS 准备再次发送文件。

这就是我处理这个问题的方式,我试图通过检查持续时间来解决它,如果它停留在 0 超过 2 秒,我做了这个和那个,但我无法修复它。我也尝试使用以前版本的 UGS,即使在那个版本中也会出现此问题,但频率较低。
** 顺便说一下,我所有的尝试都是在 RPİ 3 环境中进行的。

工作通常不会正确结束 #718
合作者

@dmavrikakis我们与#759一起进行了一些更改,也可以解决此问题。如果您有时间尝试最新的每晚构建并确认问题已解决,我将不胜感激。

工作通常不会正确结束 #718 breiler 自己分配了这个 2018 年 4 月 4 日
工作通常不会正确结束 #718
合作者

我无法重现该问题,因此我将其关闭。