注释
@timryder: 从你在另一个帖子中所说的来看,你的设置肯定很奇怪。我认为首先您需要尝试通过使用稳定的主版本来隔离问题,并完全从系统的其余部分中拔出。所以只有你的电脑和arduino。使用我们的 repo、UGS 和/或其他东西中的 stream.py 脚本,使用不同的流协议对其进行测试。 |
好的,所以我用十几种不同的格式对它进行了极大的测试。 我正在使用 G-Code Sender 作为我的测试工具,我无法获得包中包含的示例脚本来编译和运行。我将已经编译的 Grbl v0.9a Build 2013-03-19 从这个网站刷到了Arduino Uno. 我使用了我的机器典型设置。 $0=640.0000 (x, step/mm) 使用此配置并以 F40 运行机器,我还没有将其锁定。 有人愿意发表评论吗? |
更新: 截至美国东部标准时间 6 月 5 日下午 1 点(同一天),我使用 M8 M9 在我的机器上运行了 100 个冗长的 gCode 循环来驱动我的工具的输出,一旦我降低了我的 Max Speed 和 Max Accel 的值,它就没有一次停止。 我没有改变任何其他东西。 |
任何人?只要最大速度很慢,我仍然可以正常运行。任何人请注意评论? |
我可以肯定地想象 grbl 的状态机代码中存在竞争条件。这会使它对时间问题很敏感,因此依赖于最大速度等。 |
@timryder: 抱歉延迟回复。我一直忙于一些家庭事务。 您发现的这个问题是 v0.9e dev 应该解决的问题。如果您驱动它们足够快且足够快,并且 CPU 无法跟上并破坏规划器缓冲区,则像 v0.9a 这样的旧版本会锁定。V0.9e 从头开始重新设计以完全缓解这种情况。 简单地说,只是让你的机器运行得慢一些,让它在 pre 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 Programmer 在 ICSP 引脚上将 .hex 烧写到 Uno,而不是通过 USB 干扰引导加载程序。但我不明白这会有什么不同。 |
只是为了支持桑尼的方式:我认为你的 您是否将控制器引脚连接到继电器?如果您
如果您遇到相同的问题,我很想知道是否将相同的十六进制加载到已知良好的控制器上。我的猜测(使用过许多 如果您想压缩并将您的 hex 文件和 NC 文件发送给我以进行测试, -爱德华 2014 年 6 月 10 日星期二上午 8:39,timryder notifications@github.com写道:
|
@timryder: 好的,我认为一个误解是 Grbl v0.9a 将不会继续使用。此分支(边缘)将被当前 v0.9e 开发分支覆盖。v0.9e 是 v0.9a 的“更稳定”版本。因此,为什么字母后缀在字母表中更靠后。 话虽如此,请忽略来自 0.9a 的所有错误。不要使用它。如果要使用任何非主分支,此时仅使用 v0.9e 开发分支。 再一次,我想我之前已经说过了,M8/9 的问题还在继续。尚未为此发布任何修复程序。除此之外,据我所知,v0.9e 应该没有其他重大问题。如果我正确理解您的帖子,v0.9e 不会像 v0.9a 那样遇到速度和线路溢出错误问题。 |
你在之前的帖子中提到过 (您发现的这个问题是 v0.9e dev 应该解决的问题。如果您驱动它们足够快且足够快,并且 CPU 无法跟上并破坏规划器缓冲区,则像 v0.9a 这样的旧版本会锁定。 V0.9e 从头开始重新设计以完全缓解这种情况。) 我假设这是针对您已修复的 M8 M9 问题。我已经对其进行了 TON 测试,并且发现了一些发现。当电机速度较低时,该问题似乎不会发生。我在此线程开头的帖子只是重申,如果我保持低速度,我根本没有看到问题(M8 和 M9)。实际上它似乎更多地与加速度有关。由于当 M8 和 M9 发生时我的大部分动作都很小,机器在此期间从未达到峰值速度,因此在我的程序中打开 M8 M9 时,它保持在加速减速曲线中。因此,当我降低速度时,它根本不会挂在 M8 M9 上。 问题 2 我在较高波特率下遇到“线路溢出”,这实际上可能是我的 MCU。我在我的硬件上做了一个环回测试,看起来不错,但是当我编写一个小程序将串行 RX 回显到 TX 并将其闪存到 MCU 以测试我的所有硬件时,如果字符串有时太长,我偶尔会得到一些奇怪的数据。我会对此进行更多调查。 |
@timryder: v0.9e 中规划器和步进器界面的重新设计与这个 M8/9 问题完全不同。如果您查看问题线程,它通常被称为不受保护的计划程序,这是由计划程序缓冲区饥饿和第一个/当前计划程序缓冲区块同时被重写和执行引起的。v0.9e 没有这个问题。 如果您正在努力驾驶 v0.9e,您可能会遇到与 M8/9 不同的问题。这“可能”是由于新的步进中间缓冲区被饿死造成的。它只存储了 50ms 的运动,如果有太多其他的事情发生,它会破坏 Grbl。虽然在我的测试中,我从来没有遇到过问题,但也许你是出于某种原因。 尝试两件事,看看它会改变什么:
问题 2:我记得串行波特率计算可能很挑剔。根据计算的执行方式,数值四舍五入可能会导致主机和 Grbl 出现一些同步问题。我没有像你一样在 38400 波特下测试过它,但是 115200 波特是如何工作的?我认为有一些替代方法可以计算 serial.c 中的波特率,但我没有时间在不久的将来研究它。 |
@timryder: 你奇怪的通讯问题有更新吗? |
我想我知道是什么导致了 9e 上的 M8/M9 问题。我一直在为 9e 更新模拟器,并且在尝试运行 M3 主轴时看到了类似的锁定。 仅当您发送串行命令的速度超过 grbl 可以跟上的速度时,才会出现此问题。这与主循环在清空传入的串行缓冲区之前不会设置 CYCLE_START 的事实有关,但主轴和冷却剂命令会阻塞,直到规划器为空。事件的顺序是这样的: 以空闲状态启动。 这就是卡住的地方。Grbl 还没有处于“循环”状态,并且有一个当前块,所以它进入等待循环。但 我可以通过在“coolant_run”和“spindle_run”的开头添加“protocol_auto_cycle_start()”来修复它。 |
我的代码中也有这些。:-) |
@ashelly: 啊谢谢解释。这个周末我有一些时间,然后我计划解决这个问题以及其他一些事情。我一直在考虑如何整体解决这个问题,而不是一个补丁。可能会重新组织代码以在以后消除此类问题,或者在下一次使其非常明显。 |
蒂姆瑞德 评论 2014 年 6 月 5 日
好的,所以我知道这个问题之前已经提出过,但是我遇到了一些问题,我想知道这是由已知问题引起的还是我做错了什么。
基本上,我将大量 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 中尝试过这个。
有人可以评论这是一个已知问题还是新问题。