开源改变世界

缓冲区同步导致 GRBL 停止运行 GCode #427

推推 grbl 3年前 (2022-10-30) 328次浏览 0个评论
关闭
timryder 打开了这个问题 2014 年 6 月 5 日 · 23 条评论
关闭

缓冲区同步导致 GRBL 停止运行 GCode#427

timryder 打开了这个问题 on 5 Jun 2014 · 23 条评论

注释

@timryder

好的,所以我知道这个问题之前已经提出过,但是我遇到了一些问题,我想知道这是由已知问题引起的还是我做错了什么。

基本上,我将大量 gCode 发送到 grbl,它可以很好地解析模态命令,但是在使用 M8、M9 和 G4 等非模态命令时会出现问题,它并不是一直为我做,而是有点随机它发生在我身上,在我将 M8 或 M9 线发送给它之后,grbl 不会以“ok”响应。老实说,我认为它实际上并没有处理 G9 命令,因为输出仍然存在。

所以我关闭了我的应用程序中的 COM 端口,这会杀死我将程序的 gCode 发送到 grbl 的线程,并立即开始恢复获取状态“?”的线程。这似乎工作正常,它从 grbl 获得状态而没有任何打嗝。我会注意到机器的状态是……

接收:<运行,MPos:0.6002,0.7403,0.0000,WPos:0.6002,0.7403,0.0000>

所以 grbl 仍然说它正在运行。我发送一个 ~ 来恢复,但没有任何反应。然后我将它发送一个 M2 进行软重置,但没有再次发生。我尝试向它发送任何我可以处理的命令,但没有任何响应。我必须断开 MCU 的电源才能让设备再次工作。我已经在我的自定义硬件和 Uno 中尝试过这个。

有人可以评论这是一个已知问题还是新问题。

@chamnit

@timryder: 从你在另一个帖子中所说的来看,你的设置肯定很奇怪。我认为首先您需要尝试通过使用稳定的主版本来隔离问题,并完全从系统的其余部分中拔出。所以只有你的电脑和arduino。使用我们的 repo、UGS 和/或其他东西中的 stream.py 脚本,使用不同的流协议对其进行测试。

@timryder

好的,所以我用十几种不同的格式对它进行了极大的测试。

我正在使用 G-Code Sender 作为我的测试工具,我无法获得包中包含的示例脚本来编译和运行。我将已经编译的 Grbl v0.9a Build 2013-03-19 从这个网站刷到了Arduino Uno. 我使用了我的机器典型设置。

$0=640.0000 (x, step/mm)
$1=640.0000 (y, step/mm)
$2=640.0000 (z, step/mm)
$3=2400.0000 (x max rate, mm/min)
$4=2400.0000 (y max rate, mm/min)
$5=2400.0000 (z max rate, mm/min)
$6=1024.0000 (x accel, mm/sec^2)
$7=1024.0000 (y accel, mm/sec^2)
$8=1024.0000 (z accel, mm /sec^2)
$9=80.0000 (x max travel, mm)
$10=50.0000 (y max travel, mm)
$11=200.0000 (z max travel, mm)
$12=15 (step pulse, usec)
$13=0 (step port反转掩码:00000000)
$14=64(dir 端口反转掩码:01000000)
$15=0(步空闲延迟,毫秒)
$16=0.0200(结偏差,毫米)
$17=0.0020(弧度公差,毫米)
$18=4(n-小数,整数)
$19=1(报告英寸,布尔值)
$20=1(自动启动,布尔值)
$21=0(反转步进启用,布尔值)
$22=0(反转限制引脚,布尔值)
$23=0(软限制,布尔值)
$24=0 (硬限制,布尔值)
$25=1(归位周期,布尔值)
$26=192(归位目录反转掩码:11000000)
$27=1200.0000(归位进给,毫米/分钟)
$28=500.0000(归位寻道,毫米/分钟)
$29= 100(归位去抖动,毫秒)
$30=0.0000(归位拉断,毫米)

使用此配置并以 F40 运行机器,我还没有将其锁定。
$0=640.0000 (x, step/mm)
$1=640.0000 (y, step/mm)
$2=640.0000 (z, step/mm)
$3=1200.0000 (x max rate, mm/min)
$4=1200.0000 (y max rate, mm/min)
$5=1200.0000 (z max rate, mm/min)
$6=512.0000 (x accel, mm/sec^2)
$7=512.0000 (y accel, mm/sec^2)
$8=512.0000 (z accel, mm /sec^2)
$9=80.0000 (x max travel, mm)
$10=50.0000 (y max travel, mm)
$11=200.0000 (z max travel, mm)
$12=15 (step pulse, usec)
$13=0 (step port反转掩码:00000000)
$14=64(dir 端口反转掩码:01000000)
$15=0(步空闲延迟,毫秒)
$16=0.0200(结偏差,毫米)
$17=0.0020(圆弧公差,mm)
$18=4(n-decimals,int)
$19=1(报告英寸,bool)
$20=1(auto start,bool)
$21=0(invert step enable,bool)
$22=0 (反转限制引脚,布尔值)
$23=0(软限制,布尔值)
$24=0(硬限制,布尔值)
$25=1(归位周期,布尔值)
$26=192(归位目录反转掩码:11000000)
$27=1200.0000(归位进给,mm/min)
$28=500.0000 (homing seek, mm/min)
$29=100 (homing debounce, ms)
$30=0.0000 (homing pull-off, mm)

有人愿意发表评论吗?

@timryder

更新:

截至美国东部标准时间 6 月 5 日下午 1 点(同一天),我使用 M8 M9 在我的机器上运行了 100 个冗长的 gCode 循环来驱动我的工具的输出,一旦我降低了我的 Max Speed 和 Max Accel 的值,它就没有一次停止。

我没有改变任何其他东西。

@timryder

任何人?只要最大速度很慢,我仍然可以正常运行。任何人请注意评论?

@mschoer

我可以肯定地想象 grbl 的状态机代码中存在竞争条件。这会使它对时间问题很敏感,因此依赖于最大速度等。
我自己也看到过一些这样的问题。
但它们很难找到并修复。@chamnit似乎在努力追踪他们……

@chamnit

@timryder: 抱歉延迟回复。我一直忙于一些家庭事务。

您发现的这个问题是 v0.9e dev 应该解决的问题。如果您驱动它们足够快且足够快,并且 CPU 无法跟上并破坏规划器缓冲区,则像 v0.9a 这样的旧版本会锁定。V0.9e 从头开始​​重新设计以完全缓解这种情况。

简单地说,只是让你的机器运行得慢一些,让它在 pre v0.9e 上运行。您正在运行的旧 grbl 版本非常接近其极限。此外,您还可以尝试在 v0.9e 之前提高波特率。它可能有助于解决您看到的部分或全部损坏问题。

@timryder

@chamnit: 对不起,我不知道家庭的事情,家庭是你的第一要务,所以我很抱歉。这么长时间以来,您一直以快速的反应宠坏了我们,我已经开始期待它了。

我为此使用 0.9e,它似乎在更高的波特率下工作得更好,但它不断产生“线路溢出”错误,我似乎无法让它停止。所以我不得不将我的波特率降低到 9600,它摆脱了线路溢出错误。每个命令我发送的字符数不会超过 80 个,大多数情况下它们在 15-20 左右要少得多,因为我在任何时候都只发送 2 个轴。

我可以让系统运行得更慢,但我很想测试你想让我做的任何事情,以帮助解决这个问题。

@timryder

更新:在 38400 波特时,没有其他任何变化。每当我发送特定命令时,我都会不断收到错误

发送:G20
接收:错误:预期的命令信

发送:$H
接收:错误:预期的命令字母

有时在我发送 M8 和 M9 的循环中,我得到错误的数字格式。
我必须将它降低到 9600,否则它不起作用。

@chamnit

@timryder: 我想我之前在这个帖子或另一个帖子中提到过这个。您的设置有些奇怪。仅当串行数据传输超过 70 个字符而没有换行或回车时,才会发生行溢出错误。这让我认为您的流媒体存在严重问题,并且已损坏或无法正常工作。这可以解释你的很多问题,但不能解释一切。

我不能说你的控制器到底有什么问题,因为它是自定义的。我所能做的就是告诉你尝试使用真正的 arduino 来解决这个问题。

@timryder

缓冲区同步导致 GRBL 停止运行 GCode #427

真的不想在这里成为害虫,但我只想帮助你们找出问题所在,以便我们都能更好地享受这个美妙的工具!

这是 Arduino Uno 上 38400 的结果,一遍又一遍地使用 stock build 0.9e 。

编辑:我后来意识到,当我按“暂停”然后“恢复”时,控制器实际上确实恢复了我的程序。不知道有没有帮助?

@chamnit

@timryder:出于某种原因,我认为您是构建自己的 arduino 并试图修复它的用户。我的错。

无论哪种情况,您都是第一个报告此类问题的人,这意味着其他用户没有此问题,并且这与您的计算机、arduino 和编译器的组合是隔离的。

一方面,我看到你说你使用 atmel studio。我不使用 atmel studio,因为它仅适用于 Windows。我在 Mac 上工作。其次,我们选择使用 arduino ide 的内置编译器,因为它是跨平台的,并且始终使用相同的编译器。我提出这个的原因是因为 arduino IDE 编译器有点老。我无法告诉你什么样的变化会影响这种行为。据我所知,其他使用 atmel studio 的用户也没有报告过这个问题。

还有 USB 串行驱动程序。在过去,它们存在一些问题和不兼容。不能告诉你我的头顶,但那里有一些亮着的。

我认为这与您的计算机的串行通信有关。所以再次请先研究一下,并尝试模仿其他人的设置来隔离这个问题。我怀疑这是一个 grbl 问题,但在我们消除更多变量之前,我们不能排除它。

@timryder

我明白,你是对的,我确实构建了自己的硬件,所以那里没有问题。
我只是使用 make clean 重建 0.9e 代码 38400,使用 arduino IDE 的编译器生成 grbl.hex 命令行界面并将其加载到 Arduino Uno,它仍然在做同样的事情。

我在我的电脑上尝试了几条 USB 电缆和 3 个不同的 USB 端口。

不知道它还能是什么,程序似乎只是在 M8 和 M9 暂停,我必须点击暂停然后恢复才能继续。当有大量的直 G0 或 G1 序列时,它永远不会挂起,但它似乎总是停在 M8 M9。

你介意在你的设置上尝试这个文件进行测试吗?
http://www.cmt-engineering.com/gCode_Coolant.txt

我保证是安全的。

我想也许我正在做的唯一不同的事情是你们中的一些人可能没有做的是我正在使用 USBTiny Programmer 在 ICSP 引脚上将 .hex 烧写到 Uno,而不是通过 USB 干扰引导加载程序。但我不明白这会有什么不同。

@shapeoko
贡献者

shapeoko 评论 2014 年 6 月 10 日

只是为了支持桑尼的方式:我认为你的
董事会有问题。

您是否将控制器引脚连接到继电器?如果您
根本没有连接任何东西会发生什么?例如,如果它只是您的
计算机和控制器(没有屏蔽等)。

如果您遇到相同的问题,我很想知道是否将相同的十六进制加载到已知良好的控制器上。我的猜测(使用过许多
版本的 0.9)是你不会看到同样的问题。

如果您想压缩并将您的 hex 文件和 NC 文件发送给我以进行测试,
我很乐意将其加载到我的一个 arduino 上。( edward@shapeoko.com )

-爱德华

2014 年 6 月 10 日星期二上午 8:39,timryder notifications@github.com写道:

我明白,你是对的,我确实构建了自己的硬件,所以
那里没有问题。
我只是使用 make clean 重建 0.9e 代码 38400,
使用 arduino IDE 的编译器生成 grbl.hex 命令行界面并将其加载到
Arduino Uno,它仍然在做同样的事情。

我在我的电脑上尝试了几条 USB 电缆和 3 个不同的 USB 端口。

不知道它还能是什么,程序似乎只是在 M8 和 M9 暂停
,我必须点击暂停然后恢复才能继续。
当有大量的直 G0 或 G1 序列时,它永远不会挂起,但它
似乎总是停在 M8 M9。


直接回复此邮件或在 GitHub
#427(评论)上查看。

@timryder

我想这是可能的。

缓冲区同步导致 GRBL 停止运行 GCode #427
这是我的电路板和设置的图片。你可以在这里看到我使用的是 FT232RL 芯片,并且焊接的跳线直接连接到 ATMEGA328p tx 和 rx 引脚。我移除了通常位于 FT232RL USb 到串行芯片和 MCU 之间的板上的 1k 电阻器。这可以防止任何其他方式接收串行数据,除非通过这些跳线。

我做了另一个测试,只是发送了一个?一遍又一遍地使用一个名为 See-It 的串行程序,这就是这些结果。

缓冲区同步导致 GRBL 停止运行 GCode #427

在这里你可以看到几次单片机第一次没有响应?但是 2 和 3 在收到响应之前会堆积起来。随机在中间我得到那个错误,显然缓冲区中不超过 70 个字符……

我还在我的 FT232RL 串行芯片上直接焊接了一个从 TX 到 RX 的跳线,它使用一个在所有波特率下测试的程序执行了一个环回测试,它工作得很好。

请您提供任何帮助,我将不胜感激!

编辑:我意识到我在这个屏幕截图中有 XonXoff 流量控制,但我再次尝试关闭它,它仍然没有任何区别,相同的确切结果。

@timryder

埃德,

请你给它一个下载并在你的板上测试。
http://www.cmt-engineering.com/grbl.hex

http://www.cmt-engineering.com/gCode_Coolant.NC

谢谢
timryderhome@att.net

@shapeoko
贡献者

shapeoko 评论 2014 年 6 月 11 日

肯定的事。当我
今晚回来时,我会把这个十六进制放到我的一个 arduino 中。一旦我有一些信息,我会传递它。

-爱德华

2014 年 6 月 10 日星期二上午 9:51,timryder notifications@github.com写道:

埃德,

请你给它一个下载并在你的板上测试。
http://www.cmt-engineering.com/grbl.hex

http://www.cmt-engineering.com/gCode_Coolant.NC

谢谢
timryderhome@att.net


直接回复此邮件或在 GitHub
#427(评论)上查看。

@chamnit

@timryder: 好的,我认为一个误解是 Grbl v0.9a 将不会继续使用。此分支(边缘)将被当前 v0.9e 开发分支覆盖。v0.9e 是 v0.9a 的“更稳定”版本。因此,为什么字母后缀在字母表中更靠后。

话虽如此,请忽略来自 0.9a 的所有错误。不要使用它。如果要使用任何非主分支,此时仅使用 v0.9e 开发分支。

再一次,我想我之前已经说过了,M8/9 的问题还在继续。尚未为此发布任何修复程序。除此之外,据我所知,v0.9e 应该没有其他重大问题。如果我正确理解您的帖子,v0.9e 不会像 v0.9a 那样遇到速度和线路溢出错误问题。

@timryder

@chamnit

你在之前的帖子中提到过

(您发现的这个问题是 v0.9e dev 应该解决的问题。如果您驱动它们足够快且足够快,并且 CPU 无法跟上并破坏规划器缓冲区,则像 v0.9a 这样的旧版本会锁定。 V0.9e 从头开始​​重新设计以完全缓解这种情况。)

我假设这是针对您已修复的 M8 M9 问题。我已经对其进行了 TON 测试,并且发现了一些发现。当电机速度较低时,该问题似乎不会发生。我在此线程开头的帖子只是重申,如果我保持低速度,我根本没有看到问题(M8 和 M9)。实际上它似乎更多地与加速度有关。由于当 M8 和 M9 发生时我的大部分动作都很小,机器在此期间从未达到峰值速度,因此在我的程序中打开 M8 M9 时,它保持在加速减速曲线中。因此,当我降低速度时,它根本不会挂在 M8 M9 上。

问题 2 我在较高波特率下遇到“线路溢出”,这实际上可能是我的 MCU。我在我的硬件上做了一个环回测试,看起来不错,但是当我编写一个小程序将串行 RX 回显到 TX 并将其闪存到 MCU 以测试我的所有硬件时,如果字符串有时太长,我偶尔会得到一些奇怪的数据。我会对此进行更多调查。

@chamnit

@timryder: v0.9e 中规划器和步进器界面的重新设计与这个 M8/9 问题完全不同。如果您查看问题线程,它通常被称为不受保护的计划程序,这是由计划程序缓冲区饥饿和第一个/当前计划程序缓冲区块同时被重写和执行引起的。v0.9e 没有这个问题。

如果您正在努力驾驶 v0.9e,您可能会遇到与 M8/9 不同的问题。这“可能”是由于新的步进中间缓冲区被饿死造成的。它只存储了 50ms 的运动,如果有太多其他的事情发生,它会破坏 Grbl。虽然在我的测试中,我从来没有遇到过问题,但也许你是出于某种原因。

尝试两件事,看看它会改变什么:

  • 增加 ACCELERATION_TICKS_PER_SECOND。此参数定义加速斜坡中有多少个恒定速度步长。您可能会超过默认的每秒 100 次。
  • 将 SEGMENT_BUFFER_SIZE 再增加一或两个块。这将增加步进段缓冲区中的时间量,这也与 ACCELERATION_TICKS_PER_SECOND 相关。每个段缓冲区等于 1/ACCELERATION_TICKS_PER_SECOND,因此您可能需要同时调整两者。请记住,此设置会占用大量内存,因此您可能会很快用完。作为补偿,您可以将规划器缓冲区大小减小一到两个块以释放足够的内存。

问题 2:我记得串行波特率计算可能很挑剔。根据计算的执行方式,数值四舍五入可能会导致主机和 Grbl 出现一些同步问题。我没有像你一样在 38400 波特下测试过它,但是 115200 波特是如何工作的?我认为有一些替代方法可以计算 serial.c 中的波特率,但我没有时间在不久的将来研究它。

@chamnit

@timryder: 你奇怪的通讯问题有更新吗?

@ashly

我想我知道是什么导致了 9e 上的 M8/M9 问题。我一直在为 9e 更新模拟器,并且在尝试运行 M3 主轴时看到了类似的锁定。

仅当您发送串行命令的速度超过 grbl 可以跟上的速度时,才会出现此问题。这与主循环在清空传入的串行缓冲区之前不会设置 CYCLE_START 的事实有关,但主轴和冷却剂命令会阻塞,直到规划器为空。事件的顺序是这样的:

以空闲状态启动。
发送运动命令,然后立即发送冷却剂命令。
protocol main loop调用protocol_execute_line运动命令。
这将到达mc_line,它将一个块添加到规划器缓冲区并将状态设置为“排队”。
返回时,protocol main loop在缓冲区中找到更多字符并调用protocol_execute_line主轴命令。
这调用coolant_run了 which protocol_buffer_synchronize

这就是卡住的地方。Grbl 还没有处于“循环”状态,并且有一个当前块,所以它进入等待循环。但protocol_execute_runtime永远不会从 QUEUED 状态移动到 CYCLE 状态,因为没有设置“EXEC_CYCLE_START”位。

我可以通过在“coolant_run”和“spindle_run”的开头添加“protocol_auto_cycle_start()”来修复它。

@mschoer

我的代码中也有这些。:-)

@chamnit

@ashelly: 啊谢谢解释。这个周末我有一些时间,然后我计划解决这个问题以及其他一些事情。我一直在考虑如何整体解决这个问题,而不是一个补丁。可能会重新组织代码以在以后消除此类问题,或者在下一次使其非常明显。

喜欢 (0)

您必须 登录 才能发表评论!