注释
.png "Grbl 0.9c：一些测试结果 #334"){kind=avatar}
|
我遇到了同样的问题。我创建了另一个问题，因为它在这里有点隐藏。 |
.png "Grbl 0.9c：一些测试结果 #334"){kind=avatar}
|
感谢您的错误报告。请耐心等待这个错误，因为我认为找到它并编写一个好的修复程序需要一些时间。过去几周我的空闲时间有点少。我会尽快解决这个问题。 |
|
如果您还没有该信息，我可以尝试查找错误是从哪个提交开始的。 |
|
@metropt：这个错误很可能与系统状态管理有关。它过于复杂，这个问题似乎是导致系统进入排队状态而失败的情况。（如果它确实进入排队状态，循环启动应该重新启动卡住的进程。）我正在努力彻底检查整个代码库中的状态管理，以便它更直观，并希望更健壮。 |
.jpg "Grbl 0.9c：一些测试结果 #334"){kind=avatar}
|
@chamnit： 慢慢来。我只是出于好奇而进行测试，并为开发过程做出（非常小的）贡献。对我来说没问题。我将回到 0.9a。 我想进一步测试 0.9c 没有任何意义？ |
|
@chamnit您认为在以前的版本上合并 PWM 主轴控制有多难？ |
|
@metropt： 满容易。大多数代码独立于代码库的其余部分，因此可变主轴功能可以集成到几乎任何旧的 grbl 版本中。 @aldenhart: 这是确定的一种方法。Grbl 做了类似的事情，除了为循环状态创建一个子组来定义它在做什么。我可能会使用您概念的那一部分，尽管在某些地方可以进一步简化。我将不得不考虑一下。 现在，我正在研究可能适用于 grbl 的状态机概念，以控制事情的执行方式和时间。我知道 TinyG 使用调度程序和循环式概念，但我会研究我能找到的任何可以使事情变得简单和紧凑的东西。如果有人对状态机概念有任何线索，请告诉我。我不是专业的程序员，尽管我知道足够多的知识来仔细阅读堆栈溢出以获取有用的信息。 |
.png "Grbl 0.9c：一些测试结果 #334"){kind=avatar}
|
@chamnit：我或多或少使用了 Miro Samek 的方法。这是他写的一个很好的 PDF 的链接：http: 这本书叫做“C/C++ 中的实用 UML 状态图：嵌入式系统的事件驱动编程”， |
|
@aldenhart: 感谢您的链接。它似乎是关于有限状态机和有限自动机理论的好资源。 因此，昨晚，我仔细查看了代码库以及为适当的状态机进行必要更改所需的内容。看起来比我现在有时间做更多的工作，因为 g 代码解析器需要完全重写，而且我必须想出一些节省内存的技巧来处理额外的变量，这些变量将需要存储。我认为这必须等到 v1.0。 我会努力修补这个问题，而不是重构它来完全修复它，这样 v0.9 就可以更快地掌握。 |
.png "Grbl 0.9c：一些测试结果 #334"){kind=avatar}
|
@chamnit: 你需要更多的错误报告吗？或者你知道问题出在哪里吗？ 我正在使用 grbl 和 ugs https://github.com/winder/Universal-G-Code-Sender。曾经与 0.8.c 一起很好地工作。 我得到了额外的“好的”，使 ugs+grbl 组合停滞不前。 但是，如果它移动，移动（和声音）非常流畅！ |
|
感谢大家的错误报告。在新的开发版本上修复这个错误是我现在的首要任务。 |
.jpg "Grbl 0.9c：一些测试结果 #334"){kind=avatar}
|
@mschorer如果您使用的是 ugs 的 1.6 版，它将使用状态命令 (?) 向 grbl 发送垃圾邮件（我认为每 5 秒一次），以便它可以获得机器所有权。尝试使用 v1.5 ugs，看看是否可以重复您的问题。 |
|
@henols回到 1.0.5 并没有帮助。 Ugs 和 grbl 现在肯定在相互理解方面存在问题…… |
|
@mschorer：如果 v0.8c 在使用 UGS 之前工作正常并且最近发生了变化，这听起来像是另一个问题。您是否在 UGS 的 github 站点上发布了关于此的问题？您最近是否对您的设置进行过任何更改，例如系统更新或其他？ |
.png "Grbl 0.9c：一些测试结果 #334"){kind=avatar}
|
@winder： 谢谢。没有帮助。
我可以为每一步重复停止/恢复。如果我确实请求“？”，我得到： |
|
@mschorer： 行。所以 v0.8c 仍然可以正常工作，但您使用的是 v0.9 版本（无法确定它是哪个版本）。如果您使用的是 v0.9b 或 c，请不要进行进一步测试，直到我推出问题修复程序。显然，当我在 12 月试图修复一个运动问题时，它创建了一个新的问题，这是许多报告错误的来源。不是 100% 关于你的，但我会等到修复被推送。 |
.png "Grbl 0.9c：一些测试结果 #334"){kind=avatar}
|
我正在运行 0.9b，已经运行了几个星期，没有出现重大问题。您是否建议我应该降级，直到您推出一些修复程序？ |
|
@twforeman： 不必要。我不记得发布了什么 v0.9b 版本。在我搞砸之前你可能正在使用一个。如果它能正常工作，只要您不怕遇到潜在问题，就应该没问题。在大多数情况下，我认为旧的 v0.9b 版本工作得很好。它只是有一些我正在锻炼的小运动滴答声，并且比新的 v0.9c 运行得更粗糙一些，因为它没有新的步进平滑功能。 |
|
@chamnit抱歉，它是直接来自 github 的 0.9c。 是的，0.8c 正在工作，我没有抱怨……:-) 我重建了我的机器，用 0.8c 进行了测试，现在想为主轴/冷却/等集成 i2c 控制。 我会阻止测试/报告，让你做你的事。 |
今天有时间测试连接到 CNC 机器的 Grbl 09c。
首先：干得好！几乎一切都按应有的方式运行（手动时也很顺利）。归巢只是看和听的乐趣。
还测试了几个 Gcode 文件（气流铣削 +20mm 以上的材料）。我能够在没有随机警报锁的情况下保持启用硬限制。=> 似乎没问题。
但是，有一件事：主轴不会以 M3 开头，所以这是我测试过的（按顺序）
在 Grbl 源代码中：确保在 config.h 中未启用 VARIABLE_SPINDLE（否则 D11 与 D12 切换）=> 这没问题！
在连接状态（步进驱动器和传感器）和所有电源打开：
首先 M5（主轴关闭）=> gnd 和 D12 之间的电压 ~0v
然后 M3（启动主轴）=> gnd 和 D12 之间的电压 ~1.02 v（对于固态来说不够继电器）。无主轴启动。
然后我断开了机器上的所有东西并再次测量。
首先 M5 => gnd 和 D12 之间的电压 ~0v
然后 M3=> gnd 和 D12 之间的电压 ~4.68v (???)
那么现在怎么办？是软件还是硬件？
第二个测试：回到 Grbl 0.9a 并做同样的测试。
在连接状态和机器供电。
M5 => 0v
M3=> ~4.7v => 固态启动并且主轴启动（所以它不是硬件）
最后处于断开状态：
M5 => 0v
M3 => ~4.75v
也许我遗漏了什么，但我认为这是一个 Grbl 0.9c 问题/错误。
2014 年 1 月 20 日更新
今晚在 Uno 上用 0.9c 做了更多测试
外部进给保持（A1 上的接地）=> 不工作。（或者它应该是 A1 上的 5v 吗？）
循环开始 => 未测试。
外部复位（A0 上的接地）=> 复位正常。
测试了加速/减速和速度增加。多么大的进步！x、y 和 z 的当前设置现在为 300 mm/s^2 和 3000 mm/min！这台机器像真正的机器人一样说话。（据我所知，没有丢失任何步骤）。在 0.9a 中，如果不停止引擎，这些数字是不可能的。
2014 年 1 月 21 日更新：下一个不是问题，只是我的愚蠢！Grbl 似乎比我的 Gcode-streamer 可以填充串行缓冲区更快。(RTFM)
<— 可能是 G02/G03 的问题。就在每个 G03/G02 之前，运动完全停止，然后开始圆周运动。当有许多（小的）曲线要铣削时，运动不平滑但非常起伏。–>
2014 年 1 月 22 日更新：
逐行发送 gcode（并等待每行之间的“确定”）时会出现上一个问题。这是预期的（缓冲区是空的，所以没有什么可计划的）。
但是，当我尝试将串行缓冲区填充到大约 RX_BUFFER_SIZE（使用 stream.py 中的代码并将其转换为 C#）时，Grbl 本身在几行后停止发送“ok”。（s.inwait 为 false (python) 或 serialport.BytesToRead==0 (C#) 为永远）。发生这种情况之前的行数取决于每一行之间所花费的时间。我无法将完整的 gcode 文件流式传输到最后。（约 30k）。
希望这是值得的。
格兹，
罗纳德