很难说。在查看 gcode 之前，我会先更新到最新版本。

我今天会做 grbl 更新。

gCode 都是标准的，所以不足为奇。我在流式传输时从代码中删除所有不必要的字符以提高性能。然后，我根据接收到的“ok”消息，根据缓冲区级别的字节计数逐行发送。

首先，我检查了我的代码两天，但当我意识到另一个人的另一个流媒体软件有同样的问题时，我不再相信这是我自己代码中的一个错误——尤其是在 15069/60000+ 行之后。另外，使用 $C 的代码检查适用于整个文件，逐行发送并等待“确定”也适用。

一旦我有最新的 grbl 启动并运行，我会回复你。

我迁移到 1.1g，但仍然遇到同样的问题。
如果你有一台移动速度足够快的机器，那么如果你可以运行我的 gCode 来检查你是否看到同样的问题，那就太棒了。奇怪的是，我看到同样的问题出现在多个不同的流媒体应用程序上，而不仅仅是我自己的。

您的设置显示 $10=8 但根据 WIKI，此掩码的最大值为 3。$10=8 时没有缓冲区报告。但是请阅读以下内容：

此外，我使用 3 种不同的硬件（Bare Uno w/16u2、Bare Nano w/ch340g 和 ESP32 w/cp2102）在我的 GUI 上运行代码

在我停止之前，ESP32 已经超过了 17,000 行，但这是一个端口，而不是“官方”Grbl。在我的 Uno 和 nano 上运行多次后，它每次都停在 15063。我怀疑你说 15069 是因为你使用缓冲区填充，而我只使用发送响应。当它停止时，状态报告是：

<Idle|WPos:59.990,45.318,0.000|Bf:14,128|FS:0,141|Pn:XYZ>

线路挂在 F2000 S1 上，应该没问题。

请注意，规划器缓冲区在 14 处占用了一个块，串行缓冲区在 128 处完全可用。它卡在那里。我起初认为可能缺少“ok”响应，如果发生这种情况会使我的 gui 进入循环等待它，所以我修改了我的 gui 以允许强制“ok”以查看它是否会继续。mod 做了我想要的并发送了下一行，但所做的只是将报告的可用串行缓冲区减少了发送的下一行中的字符数。这是发送的行（我的发送有空格）G0 X57.461 Y47.231 状态报告转到

<Idle|WPos:59.990,45.318,0.000|Bf:14,108|FS:0,141|Pn:XYZ>

玩弄我发现发出循环启动“~”实时命令让事情再次运行。因此，系统似乎不知何故处于一种未在状态报告中报告并且不允许新命令的馈送保持状态。

所以仅供参考，我的 GUI 发送程序有一个功能可以比较回声，如果打开发送线，如果不匹配则中止。我在打开回声的情况下运行了另一次运行，程序仍然在 15063 处停止，最后一个回声行 (F2000S1) 与发送的内容相匹配。

有趣的。仅包含 F 进给和 S 速度命令的命令将强制同步缓冲区，以确保在正确的时间将主轴设置为正确的功率。如果将 S 速度命令移动到下面的 G0 行，它应该开始工作，因为 S 速度现在与运动相关联并在缓冲区中排队。

在 G0 之前似乎还有一个冗余的进给命令。您将其设置为 F2000。然后运行不使用 F 进给的 G0。然后再次将其更改为 F1500。对于激光作业，最好始终将 F 进给和 S 速度变化与运动命令结合起来，以避免强制缓冲区同步。

我怀疑您发现的是在这些缓冲区同步场景中以及在运行高速激光作业时突然出现的错误。缓冲区可能会进入不确定状态并以某种方式进入强制保持状态。还不确定为什么，但我敢肯定，如果您删除孤立的 S 和 F 命令，它会运行良好。

更正，F 进给命令不需要与运动命令一起使用。只需要改变 S 速度。这就是激光模式的设计方式

@chamnit我一直在玩弄 Grbl_ESP32 端口@bdring并在那里打开了一个关于可能相关的点动取消/进给保持的问题。我在那里报告的问题是因为我无法在 Grbl 的 AVR 版本上重现它，但它与这个问题有相似之处。我将链接该问题报告，但简而言之，点动取消或进给保持有时似乎没有完成并锁定在降低速率的状态。在这种情况下，它仍然在状态报告中显示慢跑，但相似之处是计划缓冲区报告的 14 和串行报告的 128。发出新命令与上述相同，将计划器保留在 14 并减少序列号。在这种情况下，循环启动或另一个点动取消不会纠正。似乎通过的唯一命令是软复位，它当然会由于运动中的复位而产生警报。我认为在这里提出这个问题可能会帮助您缩小正在发生的事情的范围。

bdring/Grbl_Esp32#91

编辑：我在看到所有其他回复之前写了这篇文章。我现在正在阅读它们。

谢谢！！这比我对 grbl 配置和状态响应的有限理解所允许的要深入得多。

我没有打开响应回声来提高光栅雕刻的性能。我可能会尝试您描述的内容并实现类似的回声比较功能。

However, since you did confirm my symptoms, where does this leave us? Is it possible the 328p version of grbl running on my Nano clone is somehow corrupted and has a bug? IRQ overrun? I ran into this several times in the past and always suspected my own gcode sender. But it was never this reproduceable, especially even using a different GUI and now even different machines.

Many people may disagree and there are certainly many people running Grbl on Nano clones, but I personally only use the nano anymore for testing my GUI. The reason is because of this issue.

https://github.com/gnea/grbl/wiki/Known-Issues#usb-to-serial-transmission-errors

While it is rare, the data transmission error does crop up. A non-reproducible error could be due to the random data corruption of the ch340 usb to serial chips used on many clones. The problem was found several years ago, and very well may have been corrected, but there is no way to confirm. Indeed the nano I used above showed no data corruption during the echo compare run of your files and is a newer clone I bought within the last 6 months or so. It could it be that they have updated the firmware, but based on my past experiences there just isn’t a good reason for me to risk it when a Uno clone with a 16U2 is only about $5. Others can disagree, but for me I won’t run an actual machine with a Nano clone. I believe the genuine Nano uses a FTDI chip and that may be ok but would need testing. I have test programs of millions of lines. Sounds extreme, but if the program doesn’t complete, even if it got through 90% of the file then that MCU is in my book disqualified from use on a machine. I still use them when programming my GUI, and have experienced random issues. I can’t remember the specifics, but had a feature addition to my GUI that wasn’t going right and tried and tried and tried debugging my code. Finally I switched to the UNO and everything worked without code changes in my GUI. These kind of things don’t inspire confidence. Just my opinion. Your mileage may vary.

Interesting. I heard about this and read up on the 340 issue. However, all of my clones have that chip and I never ran into corrupted data or undesired machine motion once. I use it on my PCB mill as well as on my custom K40 CO2 laser. However, I do feel like an upgrade is in order at some point.

But the issue discussed above is unrelated to the 340 issue as you and I have the same problem running the same gcode on multiple different machines, firmwares, and gcode senders!

The jog and state machine issue may be related to this but I think only in relation that the state machine might be doing something funky. It’s not completely clear what is triggering this laser issue exactly. It’s more likely it’s something in the laser code that isn’t as robust as it should be. Once again, this laser program issue should be rectified if you try to do what I suggested. If it works, let me know.

I can already confirm that my raster engraving gcode is using your suggested gcode syntax and does work. I’m implementing the changes for the vector engraving now. It’s mostly converting the gcode from what FlatCAM outputs to what you suggested:
G0XxYxFxSx and the same for G1, instead of running FS separately from the motion commands.

Yes this particular issue is not related to data corruption. however, when you say

However, all of my clones have that chip and I never ran into corrupted data or undesired machine motion once.

I would argue that you really don’t know because the data corruption is insidious and is usually the result of dropped bytes. For example if you send the following lines of code to grbl

G1 X4.453 Y6.907
G1 X4.480 Y6.904
G1 X4.503 Y6.899
G1 X4.528 Y6.891

the data corruption could be something like dropping only the characters below that are bounded by the brackets below

G1 X4.453 Y6.9[07
G1 X4.480 Y6.90]4
G1 X4.503 Y6.899
G1 X4.528 Y6.891

so Grbl would see this

G1 X4.453 Y6.94
G1 X4.503 Y6.899
G1 X4.528 Y6.891

where an entire command was lost but Grbl didn’t receive any invalid commands. So, Grbl would not throw an error. Above is a good example of what might not be picked up as the short moves in the above code and the short distance would probably not be perceptible to the eye.

This is just a hypothetical example but in my testing of the ch340 chip I found this kind of thing going on where what Grbl gets isn’t right. Whether it would in reality cause a problem depends on the exact nature of what got lost. This is exactly the reason that I implemented an echo-compare feature in my GUI. Incidentally, the way I found the problem was when implementing character counting protocol. When the above happens you get one less “ok” response and the GUI eventually stopped sending thinking the buffer was full when it was not.

Until we have a hardware/software setup that can perform error-checking of the transmitted data I have abandoned character-counting from my GUI. For my current purpose using Grbl on a milling machine it doesn’t cost me anything as the send-response is plenty fast enough for milling operations. I understand this probably isn’t an option for some uses, particularly laser use, where throughput speed is very important, but is what I do on my mill.

I reconfigured the latest FlatCAM to output grbl_laser compatible gcode.
Now, the program runs longer but it’s also an entirely different program to send to grbl due to the different command structure.
The bad news is, it still stops after an arbitrary number of lines of gcode. Much later than the initial 15000 lines mark.

output.zip

When I reduce the max feedrate to 750 for cuts and 1000 for rapids the new codes goes all the way through.

The symptom seems to be, grbl sometimes just dies when it starves instead of stopping at the end of the last vector to wait for the next available command.

Running Grbl at 20kHz+ while doing a laser job that has very short line motions at high feed rates can overload the AVR cpu. Grbl can do about 300-400 gcode lines a second. Laser raster jobs can easily hit this threshold. This is more than likely what you are running into, given it runs fine when you lower the feed rate.

Try to run faster jobs slower or increase the distance per gcode line, ie decrease resolution. Grbl runs relatively great on the limited AVR 8-bit controller. If you need faster, there are ARM versions of Grbl that can run 3 to 5 faster.

20kHz+ 与步进速率相同。您还可以通过调整微步来降低 CNC 机器的步距/mm。这将降低您的最大步速，同时保持相同的速度。它的工作原理是为 Grbl 释放更多周期来处理和规划传入的 gcode。每次 Grbl 必须执行一个步骤时，步骤中断会调用相当多的循环开销。