注释
@timryder: 从你在另一个线程中所说的来看,你的设置肯定有些奇怪。我想首先你需要尝试通过使用稳定的主版本来隔离问题并完全从你的系统的其余部分拔掉。所以只有你的电脑和arduino。使用我们的 repo、UGS 和/或其他东西中的 stream.py 脚本,使用不同的流协议对其进行测试。 |
好的,所以我用十几种不同的格式对它进行了极大的测试。 我正在使用 G-Code Sender 作为我的测试工具,我无法获得包中包含的示例脚本来编译和运行。我将已经编译好的 Grbl v0.9a Build 2013-03-19 从这个网站刷到Arduino Uno. 我使用了我的机器典型设置。 $0=640.0000(x,步长/mm) 使用此配置并以 F40 运行机器,我还没有让它锁定。 有人愿意发表评论吗? |
更新: 截至美国东部时间 6 月 5 日下午 1 点(同一天),我使用 M8 M9 在我的机器上运行了 100 个冗长的 gCode 循环来驱动我的工具输出,并且一旦我降低了我的最大速度和最大加速度的值,它就没有一次停止。 我没有改变任何其他东西。 |
任何人?只要最大速度很慢,我仍然可以跑得很好。有人愿意发表评论吗? |
我绝对可以想象 grbl 的状态机代码中存在竞争条件。这会使它对时序问题敏感,因此依赖于最大速度等。 |
@timryder: 抱歉延迟回复。我一直在忙一些家庭事务。 您发现的这个问题是 v0.9e dev 应该修复的问题。像 v0.9a 这样的旧版本如果你用力和足够快地驱动它们并且 CPU 无法跟上并破坏规划器缓冲区,就会锁定。V0.9e 从头开始重新设计以完全缓解这一问题。 简单地说,只需将您的机器运行得更慢,即可使其在 v0.9e 之前的版本上运行。您运行的旧 grbl 版本非常接近其限制。此外,您还可以尝试在 v0.9e 之前提高波特率。它可能有助于修复您看到的部分或全部损坏问题。 |
@chamnit:抱歉,我不知道家庭问题,家庭是您的第一要务,所以我很抱歉。这么长时间以来,您一直以快速响应宠坏了我们。 我为此使用 0.9e,它似乎在更高的波特率下工作得更好,但它不断产生“线路溢出”错误,我似乎无法让它停止。所以我不得不将我的波特率降低到 9600,它摆脱了线路溢出错误。我从来没有为每个命令发送超过 80 个字符,大多数时候它们在 15-20 左右要少得多,因为我随时只发送 2 个轴。 我可以让系统运行得更慢,但我很乐意测试您希望我做的任何事情,以帮助解决问题。 |
更新:在 38400 波特时,没有其他变化。每当我向它发送特定命令时,我都会收到错误消息 发送:G20 发送:$H 有时在我发送 M8 和 M9 的周期中,我得到错误的数字格式。 |
@timryder: 我想我之前在这个线程或另一个线程中提到过这个。您的设置有些奇怪。仅当串行数据传输超过 70 个字符而没有换行或回车符时,才会发生行溢出错误。这让我认为您的流式传输存在严重问题,并且损坏或无法正常工作。这可以解释你的很多问题,但不能解释所有问题。 我不能说你的控制器到底出了什么问题,因为它是自定义的。我所能做的就是告诉你尝试使用真正的 arduino 来解决这个问题。 |
@timryder:出于某种原因,我认为您是构建自己的 arduino 并试图修复它的用户。我的错。 无论哪种情况,您都是第一个报告此类问题的人,这意味着其他用户没有此问题,并且这与您的计算机、arduino 和编译器的组合是孤立的。 其一,我看到你说你使用 atmel studio。我不使用 atmel studio,因为它只适用于 windows。我在 mac 上工作。其次,我们选择使用 arduino ide 的内置编译器,因为它是跨平台的,并且自始至终都是相同的编译器。我之所以提出这个问题是因为 arduino IDE 编译器有点旧。我无法告诉你什么样的变化会影响这种行为。据我所知,其他使用 atmel studio 的用户也没有报告过这个问题。 还有usb串口驱动。在过去,它们存在一些问题并且不兼容。不能告诉你我的头顶,但那里有一些点亮。 我认为这与您计算机的串行通信有关。所以再次请先研究这个问题并尝试模仿其他人的设置来隔离这个问题。我怀疑这是一个 grbl 问题,但在我们消除更多变量之前我们不能排除它。 |
我明白,你是对的,我确实构建了自己的硬件,所以没有问题。 我在我的电脑上尝试了几种 USB 电缆和 3 个不同的 USB 端口。 不确定它还能是什么,程序似乎只是在 M8 和 M9 暂停,我必须先点击暂停然后再继续才能让它继续。当有大量直接的 G0 或 G1 时,它永远不会挂起,但它似乎总是停在 M8 M9 处。 您介意在您的设置中尝试使用此文件进行测试吗? 我保证这很安全。 我想也许我正在做而你们中的一些人可能没有做的唯一不同的事情是我使用 USBTiny 编程器通过 ICSP 引脚将 .hex 烧录到 Uno,而不是通过 USB 与引导加载程序打扰。但我看不出这会有什么不同。 |
只是为了支持 Sonny 的方式:我认为你的 您是否将控制器引脚连接到继电器?如果您
如果您遇到相同的问题,我很想知道是否将相同的十六进制加载到已知良好的控制器上。我的猜测(使用过许多 如果您想压缩并发送给我您的 hex 文件和用于测试的 NC 文件, -爱德华 在 2014 年 6 月 10 日星期二上午 8:39,timryder notifications@github.com写道:
|
埃德, 请你下载并在你的板上测试。 http://www.cmt-engineering.com/gCode_Coolant.NC 谢谢 |
当然可以。当我 -爱德华 在 2014 年 6 月 10 日星期二上午 9:51,timryder notifications@github.com写道:
|
@timryder: 好吧,我认为一种误解是 Grbl v0.9a 以后不会被使用。该分支(边缘)将被当前的 v0.9e dev 分支覆盖。v0.9e 是 v0.9a 的“更稳定”版本。这就是为什么字母后缀在字母表中更靠后的原因。 也就是说,请忽略来自 0.9a 的所有错误。不要使用它。如果您打算使用任何非 master 分支,此时只使用 v0.9e dev 分支。 同样,我想我之前已经说过,M8/9 问题仍在继续。尚未为此发布修复程序。除此之外,据我所知,v0.9e 应该没有其他主要问题。而且,如果我对您的帖子的理解正确,那么 v0.9e 不会像 v0.9a 那样出现速度和行溢出错误的相同问题。 |
你在之前的帖子中提到 (你发现的这个问题是 v0.9e dev 应该修复的问题。如果你足够快地驱动它们,像 v0.9a 这样的旧版本会锁定,并且 CPU 无法跟上并破坏规划器缓冲区。 V0.9e 从头开始重新设计以完全缓解这一问题。) 我假设这是针对您已修复的 M8 M9 问题。我已经对它进行了大量测试,并且发现了一些发现。当电机速度较低时,问题似乎不会发生。我在该线程开头的帖子只是重申,如果我保持低速度,我根本没有看到问题(M8 和 M9)。实际上它似乎更多地与加速度有关。因为当 M8 和 M9 发生时我的大部分动作都很小,机器在此期间从未达到峰值速度,所以在我的程序中打开 M8 M9 时它保持在加速减速配置文件中。因此,当我降低速度时,它根本不会挂在 M8 M9 上。 第 2 期我在较高波特率下遇到“线路溢出”,这实际上可能是我的 MCU。我在我的硬件上做了一个环回测试,它看起来很好但是当我写一个小程序来将串行 RX 回显到 TX 并将其闪存到 MCU 以测试我的所有硬件时,如果字符串太长有时我偶尔会得到一些奇怪的数据。我会对此进行更多调查。 |
@timryder:v0.9e 中规划器和步进器界面的重新设计与此 M8/9 问题完全不同。如果您查看问题线程,它通常被称为不受保护的规划器,这是由规划器缓冲区不足和第一个/当前规划器缓冲区块同时被重写和执行引起的。v0.9e 没有这个问题。 如果您正在努力驾驶 v0.9e,您可能也会遇到与 M8/9 不同的问题。这“可能”是由新的步进中间缓冲区不足引起的。它只在其中存储 50 毫秒的运动,如果发生太多其他事情,它会破坏 Grbl。虽然在我的测试中,我从来没有遇到过问题,但也许你是出于某种原因。 尝试两件事看看它会改变什么:
问题 2:我确实记得串行波特率计算可能很挑剔。根据计算的执行方式,数字舍入可能会导致主机和 Grbl 出现一些同步问题。我没有像你那样在 38400 波特率下测试过它,但是 115200 波特率是如何工作的?我认为在 serial.c 中有一些替代方法可以计算波特率,但我近期没有时间研究它。 |
@timryder: 是否有关于您奇怪的通讯问题的最新消息? |
我想我知道是什么导致了 9e 上的 M8/M9 问题。我一直在为 9e 更新模拟器,并且我已经看到类似的锁定试图运行 M3 主轴。 只有当您发送串行命令的速度快于 grbl 可以跟上时,才会出现此问题。它与以下事实有关:主循环在清空传入串行缓冲区之前不会设置 CYCLE_START,但主轴和冷却液命令会阻塞,直到规划器为空。事件的顺序是这样的: 以空闲状态启动。 这就是它卡住的地方。Grbl 还没有处于 ‘CYCLE’ 状态,并且有一个当前块,所以它进入等待循环。但 我能够通过在“coolant_run”和“spindle_run”的开头添加“protocol_auto_cycle_start()”来修复它。 |
我的代码中也有这些。:-) |
@ashelly: 啊,谢谢你的解释。这个周末我有一些时间,然后我打算解决这个问题以及其他一些事情。我一直在考虑如何从整体上解决这个问题,而不是补丁。可能会重新组织代码以在以后消除此类问题,或者在下一次使它变得非常明显。 |
好的,我知道这个问题之前已经提出过,但我遇到了一些问题,我想知道这是由已知问题引起的还是我做错了什么。
基本上,我将大量的 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 中都尝试过这个。
有人可以评论这是已知问题还是新问题。