更新：我尝试将 X0 添加到三行代码中，但没有帮助。CNCjs 仍然检测到错误。

在不知道由先前上下文建立的起始位置的情况下，不可能解释 G2 弧。

要指定弧线，您需要 3 个点 – 起点终点中心。即使在 G2 命令中列出了所有 XYZ 的最佳情况下，也只有终点在没有上下文的情况下是完全已知的。

除了无法在没有上下文的情况下确定起点和中心之外，在不知道有效的模态工作平面的情况下也无法解释弧

当您说“CNCjs 正在检测错误”时，您到底是什么意思？您是否在串行控制台窗口中看到错误报告？如果是这样，报告文本究竟是什么？

该信息至关重要，因为在许多情况下，CNCjs 实际上并不直接“检测”错误，而是传递由 Grbl 或 TinyG 或其他任何生成的错误报告——并且错误的“检测”发生在 Grbl 中。如果发生这种情况，则无法从 CNCjs 代码确定哪里出了问题；相反，必须深入研究 Grbl 代码——为此需要了解 Grbl 版本，有时还需要了解详细的机器配置。

在错误报告中包含屏幕截图可能是简单调试会话和不可能调试会话之间的区别。

是的，在串行控制台窗口中，它停止了 g 代码的处理，询问我是否要恢复。它报告代码错误并报告代码行，也就是我上面提到的三行。如果我再次看到它，我会剪下它并发布。我很乐意将问题发布到 GRBL 页面上。但是，我修改了操作，但我再也看不到它了。

如果你pm2在你的树莓派上使用，你可能会pm2 monit在开始工作之前运行并观察是否有什么东西干扰了 cncjs 实例。

那么，既然问题已经无法重现，那么关闭这张ticket可以吗？

有关最近可能相关的一些工作，请参阅#233 。默认情况下，CNCjs 策略是在控制器报告错误时暂停，但现在可以配置选择性地忽略特定错误。

由于错误发生在 gcode arc 期间，最有可能的错误是来自 grbl 的“gcode.c”中这些行的 STATUS_GCODE_INVALID_TARGET (33)

            // Compute difference between current location and target radii for final error-checks.
            float delta_r = fabs(target_r-gc_block.values.r);
            if (delta_r > 0.005) { 
              if (delta_r > 0.5) { FAIL(STATUS_GCODE_INVALID_TARGET); } // [Arc definition error] > 0.5mm
              if (delta_r > (0.001*gc_block.values.r)) { FAIL(STATUS_GCODE_INVALID_TARGET); } // [Arc definition error] > 0.005mm AND 0.1% radius
            }

基本上这意味着 grbl 试图从起点、终点和中心计算出弧的细节，但看起来从中心到起点的半径与从中心到终点的半径不同。一种可能发生的情况是计算中的舍入误差使事情看起来不同，即使它们非常接近。该代码试图处理“足够接近”，但这样做的数学可能会变得棘手。

此外，在完整的 UI 中对此进行模拟时，完整的 UI 将允许我恢复并且 g 代码文件继续在错误处暂停的位置。但是，当使用平板电脑用户界面运行 g 代码文件时，它会返回到 g 代码的开头，因此当我按下恢复时，它会从 g 代码文件的开头重新开始操作。

你好@MitchBradley

根据所提到的事实@ENGR-mike，我可以通过在 G 代码文件中手动插入不受支持的命令来重现此问题。如果遇到错误，我可以从主 UI 恢复程序执行：

但是，如果我尝试从平板电脑用户界面恢复作业，它总是会触发“gcode:start”命令，因此它会回到 G 代码的开头。
https://github.com/cncjs/cncjs-shopfloor-tablet/blob/master/src/index.html#L81

要在平板电脑 UI 中修复此问题，您必须根据当前工作流状态确定是开始还是恢复作业，工作流状态可以通过 ‘workflow:state’ 事件检索，见下文：
https://github .com/cncjs/cncjs-shopfloor-tablet/blob/master/src/controller.js#L103

// Workflow State
var WORKFLOW_STATE_RUNNING = 'running';
var WORKFLOW_STATE_PAUSED = 'paused';
var WORKFLOW_STATE_IDLE = 'idle';

// Start
if (cnc.controller.workflowState === WORKFLOW_STATE_IDLE) {
    cnc.controller.command('gcode:start');
    return;
}

// Resume
if (cnc.controller.workflowState === WORKFLOW_STATE_PAUSED) {
    cnc.controller.command('gcode:resume');
    return;
}

您可能必须使用上面的示例更新 index.html 中的代码：

<div class="col-xs-2">
    <button type="button" class="btn btn-default btn-start" onclick="cnc.controller.command('gcode:start')">
        Start
    </button>
</div>

@ENGR-mike

有一个已知问题我需要在这里提到，CNCjs 使用字符计数流协议以激进的方式将 G 代码程序发送到 Grbl，因此报告的错误行可能不是您的 G 代码文件中的确切行. 该错误可能发生在报告的行数之前或之后。

@cheton– 感谢您查看这个。我刚睡醒，正准备自己去看。我想研究控制器状态和工作流状态之间的所有不同交互。理想情况下，如果控制器被完全抽象到 UI 代码本身不需要知道哪个控制器有效，那将会很好，但我认为这需要一些工作才能实现。同时，我想处理暂停/停止/恢复 GCode 流程和长点动操作的情况。

我想这意味着问题将保持开放状态？

我开始了解情况的全部复杂性。CNC 控制器中的缓冲可以导致有趣的状态组合。例如，考虑这个简单的 GCode 程序：

G21 G1 X40 F400
G0 X0
M30

G1 命令在 CNC 控制器上运行需要一定的时间（在本例中为 6 秒，但在一般情况下，一条命令可能需要很长时间）。同时，CNCjs已经进行到M30指令，已经进入workflow:paused状态。因此，在很长一段时间内，总状态是“grbl:state = Run”和“workflow:state = paused”。

当 Grbl 在 GCode 程序中遇到错误时，会出现类似的复杂情况。

很难将 Grbl CNC 控制器中的 GCode 执行与 CNCjs 计算机中的状态报告和控制同步。这是使用多台计算机实现的任何系统的固有弱点。Grbl 的局限性——Arduino 资源限制和串行线流量控制困难——使得问题特别难以很好地解决。这就是我在工厂中使用 g2core 的原因之一。g2core 在具有一定内存和处理器速度余量的 ARM 处理器上运行，因此至少有修复深层次问题的希望。

大家圣诞快乐！感谢使用 CNCjs 的所有帮助。我已经开始制造芯片，并且学习了很多关于定义与铣削能力、钻头大小等相关的操作。我将继续尽我所能帮助 CNCjs 变得更好。

PS 我还在 Shopfloor-Tablet 页面上提交了一个问题。

你好@MitchBradley

为了简单起见，您可以依靠工作流状态来更改每个按钮的禁用状态，以控制开始（或恢复）、暂停、停止操作，如下所示：
https ://github.com/cncjs/cncjs/blob/master/ src/web/widgets/Visualizer/WorkflowControl.jsx#L82-L139

const isReady = canClick && gcode.ready;
const canRun = this.canRun();
const canPause = isReady && (workflow.state === WORKFLOW_STATE_RUNNING);
const canStop = isReady && (workflow.state === WORKFLOW_STATE_PAUSED);
const canClose = isReady && (workflow.state === WORKFLOW_STATE_IDLE);

唯一（或最）复杂的是canRun功能，您可以参考代码https://github.com/cncjs/cncjs/blob/v1.9.12/src/web/widgets/Visualizer/WorkflowControl.jsx# L82-L129看看它是如何实现的。

以下是用于工作流控制的处理函数：
https ://github.com/cncjs/cncjs/blob/v1.9.12/src/web/widgets/Visualizer/index.jsx#L351-L419

handleRun: () => {
    const { workflow } = this.state;

    if (workflow.state === WORKFLOW_STATE_IDLE) {
        controller.command('gcode:start');
        return;
    }
    if (workflow.state === WORKFLOW_STATE_PAUSED) {
         controller.command('gcode:resume');
    }
},
handlePause: () => {
     const { workflow } = this.state;
     controller.command('gcode:pause');
 },
 handleStop: () => {
    const { workflow } = this.state;
    controller.command('gcode:stop', { force: true });
},
handleClose: () => {
    const { workflow } = this.state;
    controller.command('gcode:unload');
    pubsub.publish('gcode:unload'); // Unload the G-code
}

对于缓冲引起的同步问题，这不是Grbl的问题。Grbl 为发送者提供两种选择来流式传输 G 代码程序。一种是简单的发送-响应流协议，另一种是字符计数流协议。我从 Grbl 的wiki复制了部分描述：

https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface#streaming-ag-code-program-to-grbl

发送响应流协议

主机 PC 接口简单地向 Grbl 发送一行 G 代码并等待 ok 或 error：响应消息，然后再发送下一行 G 代码。因此，无论 Grbl 是否需要等待前瞻规划器缓冲区中的空间来完成解析和执行最后一行 G 代码，或者主机是否忙于做某事，这都保证了主机 PC 和 Grbl ，已编程的 G 代码已正确发送和接收。

字符计数流协议

此协议与其他协议之间的主要区别在于主机 PC 需要维护一个已发送给 Grbl 的字符数的计数，然后减去与每个 Grbl 响应执行的行对应的字符数。假设有一个简短的 G 代码程序有 5 行，分别为 25、40、31、58 和 20 个字符（也包括换行符和回车符）。我们知道 Grbl 有一个 128 个字符的串行接收缓冲区，主机 PC 最多可以发送 128 个字符而不会溢出缓冲区。如果我们让主机 PC 发送尽可能多的完整行，而不会溢出 Grbl 的串行接收缓冲区，则可以发送前三行 25、40 和 31 个字符，总共 96 个字符。当 Grbl 发送响应消息时，我们知道第一行已经被处理并且不再在串行读取缓冲区中。就目前而言，串行读取缓冲区现在有 40 行和 31 行字符，总共 71 个字符。然后主机 PC 需要确定在不溢出缓冲区的情况下发送下一行是否安全。下一行为 58 个字符，串行缓冲区为 71 个字符，总共 129 个字符，主机 PC 将需要等待，直到从串行缓冲区中清除更多空间。当下一个 Grbl 响应消息进来时，第二行已经被处理，串行缓冲区中只剩下第三个 31 个字符的行。此时，可以安全地发送g代码程序剩余的最后两个58和20字符行，总共110个。串行读取缓冲区现在有 40 和 31 个字符行，总共 71 个字符。然后主机 PC 需要确定在不溢出缓冲区的情况下发送下一行是否安全。下一行为 58 个字符，串行缓冲区为 71 个字符，总共 129 个字符，主机 PC 将需要等待，直到从串行缓冲区中清除更多空间。当下一个 Grbl 响应消息进来时，第二行已经被处理，串行缓冲区中只剩下第三个 31 个字符的行。此时，可以安全地发送g代码程序剩余的最后两个58和20字符行，总共110个。串行读取缓冲区现在有 40 和 31 个字符行，总共 71 个字符。然后主机 PC 需要确定在不溢出缓冲区的情况下发送下一行是否安全。下一行为 58 个字符，串行缓冲区为 71 个字符，总共 129 个字符，主机 PC 将需要等待，直到从串行缓冲区中清除更多空间。当下一个 Grbl 响应消息进来时，第二行已经被处理，串行缓冲区中只剩下第三个 31 个字符的行。此时，可以安全地发送g代码程序剩余的最后两个58和20字符行，总共110个。下一行为 58 个字符，串行缓冲区为 71 个字符，总共 129 个字符，主机 PC 将需要等待，直到从串行缓冲区中清除更多空间。当下一个 Grbl 响应消息进来时，第二行已经被处理，串行缓冲区中只剩下第三个 31 个字符的行。此时，可以安全地发送g代码程序剩余的最后两个58和20字符行，总共110个。下一行为 58 个字符，串行缓冲区为 71 个字符，总共 129 个字符，主机 PC 将需要等待，直到从串行缓冲区中清除更多空间。当下一个 Grbl 响应消息进来时，第二行已经被处理，串行缓冲区中只剩下第三个 31 个字符的行。此时，可以安全地发送g代码程序剩余的最后两个58和20字符行，总共110个。

保留：
如果 g 代码行被解析并生成错误响应消息，则 GUI 应立即停止流。然而，由于字符计数方法填充了 Grbl 的 RX 缓冲区，Grbl 将继续从 RX 缓冲区读取并解析和执行其中的命令。GUI 将无法控制它。临时解决方案是通过 $C 检查模式检查所有 g 代码，以便在流式传输之前检查所有错误。这将在更高版本的 Grbl 中得到解决。

在当前的实现中，我选择使用字符计数作为 Grbl 和 Smoothie 控制器的默认流协议，以实现高性能，尤其是对于低成本的 Arduino 板，但它可以通过仅更改一行来切换为使用发送响应协议代码

从

this.sender = new Sender(SP_TYPE_CHAR_COUNTING, { /* options */ });

到

this.sender = new Sender(SP_TYPE_SEND_RESPONSE, { /* options */ });

如果你们都认为这是一个可配置选项所必需的，我可以将其设为可配置，以便用户可以根据自己的需要更改 Grbl 或 Smoothie 的流媒体协议设置。

为了简单起见，您可以依靠工作流状态来更改每个按钮的禁用状态，以控制开始（或恢复）、暂停、停止操作，如下所示：

我希望就这么简单。问题在于工作流状态不反映点动和 MDI 操作。我的铣床有一个 350 毫米的床身，可以 500 毫米/分钟的速度快速移动，所以长距离移动可能需要很多秒。重要的是能够在出错时暂停或​​停止慢跑；否则，您可能会弄坏昂贵的钻头或在工作台、虎钳或夹具上磨出凿痕。

到目前为止，我最好的分析是：

// workflow.state == RUNNING does not account for jog and MDI
canPause = grbl.activeState == RUN;  
canStop =  grbl.activeState == HOLD || grbl.activeState == RUN;
canResume = (grbl.activeState == HOLD || (grbl.activeState == IDLE && workflow.state == PAUSED);

对于缓冲引起的同步问题，这不是Grbl的问题。

我不是在谈论串行缓冲区流控制，而是确定 CNC 控制器在其执行过程中取得了多大进展的问题。这会影响错误消息的解释和 gcode 行的突出显示。Grbl 的串行缓冲区、规划器缓冲区和机器移动速度都对此做出了贡献。TinyG 有一种方法可以报告实际执行了哪些 GCode 行，但即使这样也存在在没有 Nxx 行号的情况下如何识别行的问题。

目前只在TinyGController.js中添加了行号检测，其他控制器的代码中没有。

https://github.com/cncjs/cncjs/blob/master/src/app/controllers/TinyG/TinyGController.js#L292-L295

// Replace line numbers with the number of lines sent
const n = this.sender.state.sent;
line = ('' + line).replace(/^N[0-9]*/, '');
line = ('N' + n + line);

Not sure if it’s worth doing for other controllers, but it’s easy to implement if you find it useful.

I wish it were that simple. The problem is that the workflow state does not reflect jogging and MDI operations. My milling machine has a 350 mm bed and can rapid at 500 mm/min, so long traverses can take many seconds. It’s important to be able to pause or stop jogs in case of a mistake; otherwise you might break an expensive bit or mill a gouge in a table, vise, or