作为参考，这是重现问题的隔离代码：

Imports System.IO.Ports
Imports System.Threading
 
Public Class frmMain
 
    Shared _serialPort As SerialPort
    Shared _continue As Boolean
    Dim readThread As Thread
 
    Private Sub btnOpen_Click(sender As Object, e As EventArgs) Handles btnOpen.Click
        _serialPort = New SerialPort()
        _serialPort.PortName = "COM12"
        _serialPort.BaudRate = 115200
        _serialPort.Parity = Parity.None
        _serialPort.DataBits = 8
        _serialPort.StopBits = StopBits.One
        _serialPort.Handshake = Handshake.None
        _serialPort.ReadTimeout = 500
        _serialPort.WriteTimeout = 500
 
        _serialPort.Open()
 
        _continue = True
        readThread = New Thread(AddressOf Read)
        readThread.Start()
 
        GroupBox1.Enabled = True
        btnOpen.Enabled = False
    End Sub
 
    Public Shared Sub Read()
        While _continue
            Try
                Dim message As String = _serialPort.ReadLine()
                Console.WriteLine(message.Trim())
            Catch
            End Try
        End While
    End Sub
 
    Private Sub btnClose_Click(sender As Object, e As EventArgs) Handles btnClose.Click
        _continue = False
        _serialPort.Close()
        GroupBox1.Enabled = False
        btnOpen.Enabled = True
    End Sub
 
    Private Sub btnReset_Click(sender As Object, e As EventArgs) Handles btnReset.Click
        _serialPort.Write(Chr(24))
    End Sub
 
    Private Sub btnStatus_Click(sender As Object, e As EventArgs) Handles btnStatus.Click
        _serialPort.Write("?")
    End Sub
 
    Private Sub btnUnlock_Click(sender As Object, e As EventArgs) Handles btnUnlock.Click
        _serialPort.Write("$X" & vbLf)
    End Sub
 
    Private Sub btnTestA_Click(sender As Object, e As EventArgs) Handles btnTestA.Click
        ' works
        _serialPort.Write("G90G10L20P0X0" & vbLf)
    End Sub
 
    Private Sub btnTestB_Click(sender As Object, e As EventArgs) Handles btnTestB.Click
        ' works
        _serialPort.Write("G38.2X-1F25" & vbLf)
    End Sub
 
    Private Sub btnTest_Click(sender As Object, e As EventArgs) Handles btnTest.Click
        ' works only every 2nd time and throws "Bad number format"
        _serialPort.Write("G90G10L20P0X0" & vbLf & "G38.2X-1F25" & vbLf)
    End Sub
End Class

@thoralt：不确定这里发生了什么，但它可能会破坏 Arduino 和您的计算机之间的通信。在 config.h 中，您可以取消注释 REPORT_ECHO_LINE_RECEIVED 选项（重新编译和刷新）以让 Grbl 在执行之前报告它收到的字符串。它将被部分解析。没有空格，全部大写，没有评论。

回声是一个很好的起点@chamnit提及。

在我正在编写的 GUI 中，我也发现一个接一个地发送命令会导致 grbl 无法正确接收命令。我不知道为什么，但即使从 GUI 发送单独的 serialport.write 命令也会发生。出于这个原因，我在发送另一个命令之前实现了等待来自 grbl 的 OK 响应。这已经解决了您在帖子中描述的所有实例。

@chamnit好的，我会检查一下。
@109JB我可以确认您观察到的行为。即使在我上面描述的问题之外，grbl 也不会时不时地执行一个动作（例如，我在探测后实现的拉断很少丢失）。这尤其令人难过，因为 grbl-panel已经在使用效果很好的“等待每个命令都OK”的方法。我正在尝试实施推荐的“缓冲区计数”方法，以获得大量小动作的额外性能，这似乎会导致这些问题。但我会评估这个REPORT_ECHO_LINE_RECEIVED选项，并在扔掉我的工作之前直接嗅探 arduino 的 RX 引脚。

当我以字符计数模式发送文件时，我正在编写的 GUI 也有些奇怪。还没有深入了解正在发生的事情，但作为一个额外的数据点，我发现如果 grbl 处于“检查”模式，我不会收到“错误数字格式”错误。

我现在确实重新编译了启用的 grbl，REPORT_ECHO_LINE_RECEIVED我看到了类似但略有不同的行为：

ok
[echo: G90G10L20P0X0]
ok
[echo: G38.2X-1]
error: Undefined feed rate

第一个命令解析得很好，而第二个命令在中间被剪切。显然，切割的点与以前不同，现在 grbl 正确地抱怨未定义的进给率。我重新编译 REPORT_ECHO_LINE_RECEIVED并返回原始错误“错误的数字格式”，它告诉我切割点发生了一些变化，但它仍然是可重现的。

我直接从 arduino 的 RX 输入中嗅出信号，请参见下面的屏幕截图。它显示有问题的传输过程中的解码字符。空字符不是空格，而是换行符（我通过放大验证）。显然，USB串行转换器正确传输了该消息。我尝试了另一个 arduino 来排除该特定硬件的任何问题，并使用了不同的品牌/不同的布局，但它显示了同样的问题。

采取的帖子@AlexHolden和@109JB考虑到，目前 grbl 的缓冲区管理中的某些内容似乎很奇怪。我怎样才能协助追查此事？我可以提供电子硬件和 AVR 开发方面的技能。

@thoralt：确保在 Grbl 的 RX 缓冲区中数到 127，而不是 128 个字符。这是一个常见的错误。（从技术上讲，我应该将 128 表示为 128，但它已经这样很久了。）

啊，我一直在使用 128。我想我可能是从 stream.py 示例中的“RX_BUFFER_SIZE=128”行得到的。

@chamnit我知道 127 字节的限制。我们在这里讨论的是一个 26 个字符的字符串，grbl 在第 22 个字符之后将其剪切。在我发送命令之前，我等待几秒钟，然后重置/解锁，所以 grbl 的缓冲区肯定是空的。干扰 22+ 字节长的命令不是缓冲区溢出问题，而是更棘手的问题。正如我所说，我愿意提供帮助，但还没有深入了解 grbl 的内部运作。

@thoralt: 如果这是 Grbl 方面的问题，那么当前的 GUI 也会出现这个问题。到目前为止，还没有报告过问题，因为这样的事情将是一个严重的问题。因此，Grbl 不太可能是问题所在，而是流式传输或与您的设置有关。

Grbl 的源代码直到它提供回声的地方都非常简单。串行读取 ISR 也很简单。在过去的几个月里，这些都没有显着变化。

请尝试不同的 GUI 或 Grbl 的流脚本。验证是否通过其他方式可以正常发送相同的 g 代码。

为了进一步深入研究这一点，我启动了我的 Mac（因为我不确定如何在 windows 下快速获得带有串行端口的工作 Python）。我从 GitHub 复制了最新版本的 stream.py。

当只进行一个探测周期时，一切似乎都很好，即使在不久之后进行另一个探测周期也是如此。但是由于 stream.py 关闭了串行连接，之后 Arduino 会重置，而在我的 VB.NET 测试设置中不是这种情况，我让连接保持打开状态。

所以我创建了一个包含多个探测周期的更长的文件。由于我目前正在离线探测而没有连接步进器，因此 grbl 进入警报状态（探测失败），因此我需要在每个探测周期后解锁。我不确定仅 $X 是否合法，然后再进行调查并重新开始，但没有找到任何反对它的信息。这是文件：

$X
G90G10L20P0X0
G38.2X-1F25
$X
G90G10L20P0X0
G38.2X-1F25
$X
G90G10L20P0X0
G38.2X-1F25
$X
G90G10L20P0X0
G38.2X-1F25
$X
G90G10L20P0X0
G38.2X-1F25
$X
G90G10L20P0X0
G38.2X-1F25
$X
G90G10L20P0X0
G38.2X-1F25
$X
G90G10L20P0X0
G38.2X-1F25
$X
G90G10L20P0X0
G38.2X-1F25
$X
G90G10L20P0X0
G38.2X-1F25
$X
G90G10L20P0X0
G38.2X-1F25

结果如下：

> python stream.py probe-test.nc /dev/cu.usbmodem1411
Initializing grbl...
SND: 1 : $X BUF: 3 REC:
SND: 2 : G90G10L20P0X0 BUF: 17 REC:
SND: 3 : G38.2X-1F25 BUF: 29 REC:
SND: 4 : $X BUF: 32 REC:
SND: 5 : G90G10L20P0X0 BUF: 46 REC:
SND: 6 : G38.2X-1F25 BUF: 58 REC:
SND: 7 : $X BUF: 61 REC:
SND: 8 : G90G10L20P0X0 BUF: 75 REC:
SND: 9 : G38.2X-1F25 BUF: 87 REC:
SND: 10 : $X BUF: 90 REC:
SND: 11 : G90G10L20P0X0 BUF: 104 REC:
SND: 12 : G38.2X-1F25 BUF: 116 REC:
SND: 13 : $X BUF: 119 REC:
  Debug:  [echo: $X]
  Debug:  [Caution: Unlocked]
  Debug:  [echo: G90G10L20P0X0]
SND: 14 : G90G10L20P0X0 BUF: 116 REC: ok1ok2
  Debug:  [echo: G38.2X-10]
SND: 15 : G38.2X-1F25 BUF: 116 REC: error: Undefined feed rate3
SND: 16 : $X BUF: 119 REC:
  Debug:  [echo: 10L20P0X0]
  Debug:  [echo: G38.2X-1F25]
  Debug:  ALARM: Probe fail
  Debug:  [PRB:0.000,0.000,0.000:0]
SND: 17 : G90G10L20P0X0 BUF: 116 REC: error: Expected command letter4ok5
  Debug:  [echo: $X]
  Debug:  [Caution: Unlocked]
SND: 18 : G38.2X-1F25 BUF: 116 REC: ok6
SND: 19 : $X BUF: 119 REC:
  Debug:  [echo: G90G10L20P0X0]
  Debug:  [echo: G38.2X-1F25]
  Debug:  ALARM: Probe fail
  Debug:  [PRB:0.000,0.000,0.000:0]
SND: 20 : G90G10L20P0X0 BUF: 116 REC: ok7ok8
  Debug:  [echo: $X]
  Debug:  [Caution: Unlocked]
SND: 21 : G38.2X-1F25 BUF: 116 REC: ok9
SND: 22 : $X BUF: 119 REC:
  Debug:  [echo: G90G10L20P0X0]
  Debug:  [echo: G38.2X-1F25]
  Debug:  ALARM: Probe fail
  Debug:  [PRB:0.000,0.000,0.000:0]
SND: 23 : G90G10L20P0X0 BUF: 116 REC: ok10ok11
  Debug:  [echo: $X]
  Debug:  [Caution: Unlocked]
SND: 24 : G38.2X-1F25 BUF: 116 REC: ok12
SND: 25 : $X BUF: 119 REC:
  Debug:  [echo: G9]
  Debug:  [echo: G38.2X-1F25]
SND: 26 : G90G10L20P0X0 BUF: 116 REC: error: Unsupported command13error: Invalid gcode ID:3314
  Debug:  [echo: $X]
SND: 27 : G38.2X-1F25 BUF: 116 REC: ok15
SND: 28 : $X BUF: 119 REC:
  Debug:  [echo: G9]
  Debug:  [echo: G38.2X-1F25]
SND: 29 : G90G10L20P0X0 BUF: 116 REC: error: Unsupported command16error: Invalid gcode ID:3317
  Debug:  [echo: $X]
SND: 30 : G38.2X-1F25 BUF: 116 REC: ok18
SND: 31 : $X BUF: 119 REC:
  Debug:  [echo: G90G10L20P0X0]
  Debug:  [echo: G38.2X-1F25]
  Debug:  ALARM: Probe fail
  Debug:  [PRB:0.000,0.000,0.000:0]
SND: 32 : G90G10L20P0X0 BUF: 116 REC: ok19ok20
  Debug:  [echo: $X]
  Debug:  [Caution: Unlocked]
SND: 33 : G38.2X-1F25 BUF: 116 REC: ok21
SND: 34 :  BUF: 117 REC:
SND: 35 :  BUF: 118 REC:
G-code streaming finished!

WARNING: Wait until grbl completes buffered g-code blocks before exiting.
  Press <Enter> to exit and disable grbl.

我不确定如何正确读取所有这些输出，但您可以在 grbl 的[echo...]语句中找到截断的命令，就像我之前在 VB.NET 中观察到的那样。第一个截断的回声似乎在SND: 14.

PS：你看我的范围截图了吗？在直接在 arduino 的 RX 引脚物理测量有效 gcode 之后告诉我“这是一个与应用程序相关的问题”，这让我很难过。

@thoralt: 没必要啰嗦。这是第一次报告此类问题的事实仍然让我认为这是您的设置（也与硬件或连接相关）或流媒体相关。我提到这可能是与应用程序相关的问题，因为它几乎总是由应用程序引起的。如果您不相信我，请检查已关闭的问题线程。这通常是由于流媒体发送了太多的字符，要么计数到 128 个字符，要么发送的字符比它想象的要多，这导致 Grbl 的 RX 缓冲区溢出。

现在您已经针对另一个流媒体进行了测试，这在很大程度上排除了流媒体。如果您可以再尝试一件事，请更改 Grbl 的串行波特率。这是在 config.h 中完成的。更改为 56700 波特或 250000 波特。由于 328p 和时钟的时序不准确，这些被认为更准确（有关详细信息，请参阅 328p 数据表）。有一份报告称 115200 波特可能会导致一些与您类似的奇怪问题，并且可能会丢失数据。即使您直接从 Arduino RX 引脚读取信号。

尝试只是一个串行终端并粘贴尽可能多的缓冲区

@thoralt: 我想我看到了问题。这是您在探测之前调用的 EEPROM 写入。接口 wiki 中有一篇关于写入 EEPROM 的文章。无论何时发生这种情况，都会在写入期间禁用所有中断，包括串行 RX。AFAIK，在 Grbl 中无法避免这个问题，因为这是 328p AVR 的基本问题。

您的流媒体必须检测这些 EEPROM 写入命令，并在发送更多数据之前等待该特定 g 代码行的确认。或者使用更简单的发送并等待响应协议。在这种情况下，写入 EEPROM 的是您的 G10L20 命令。

所以，是的，这是一个与应用程序相关的问题。不是Grbl。无论如何，我会更新 Wiki 以使这个问题更加清晰，以避免将来出现像这个问题一样的问题。

@chamnit对不起，如果你误会了我。英语不是我的母语，很难同时写出准确、礼貌和令人满意的文字。我什至不得不查找“snarky”并且绝对不想听起来那样。我理解你的论点，而 grbl 的统计数据完全推翻了我的假设。再次抱歉。

话虽如此，我用替代波特率测试了您的建议。我没有时间测试数百个探测周期（现在再次连接了步进器），但似乎错误已经消失了。波特率设置中的舍入误差可能会导致问题（我在 USB 串行转换器上测量了 119.000 输出，也许 AVR 有点偏离另一个方向），但你的第二个建议，EEPROM 写入延迟，更多可能。

在传输实际命令之前，每当发生 EEPROM 写入时，我将尝试实现类似等待队列耗尽的操作。谢谢你的线索。

@thoralt： 没问题。我有一位德国教授担任研究生导师。我花了一段时间才理解他非常直接且通常简洁的陈述是为了建设性的批评，而不是贬低或侮辱性的言论。事实证明，他是我在校期间最喜欢的教授。