注释
.png "G2弧码冻结 #106"){kind=avatar}
合作者
|
如果我从控制台小部件逐行发送命令（JSON 格式），效果会很好。您可以手动尝试： 但是，如果我批量发送整个文件，就会像您所说的那样出错 – 直线而不是弧线。我将对 Chillipeppr 进行测试并检查差异。 |
合作者
|
这是我的输出 |
合作者
|
我的固件版本是 78.02。在 Chilipeppr 的 TinyG 工作区上运行此 G 代码程序时，它对我也不起作用。有时候G2走直线，随机走法，结果出乎意料，不知道是不是和这些问题有关。 你好@jarretluft, 您有机会在 Chilipeppr 上使用 TinyG2 测试 G 代码程序吗？ |
合作者
|
我从G2 边缘分支制作了一个固件版本 100.12 ，它仍然无法在 cnc 和 Chilipeppr 上正常工作。 |
.png "G2弧码冻结 #106"){kind=avatar}
作者
|
??¡ 我用Chilipeppr 没有问题。 使用 Chilipeppr，它可以形成一个流畅的圆圈，没问题。它也可以在正方形中做一个很好的圆角。 |
.png "G2弧码冻结 #106"){kind=avatar}
|
亲爱的 Cheton，亲爱的 Gendebeat， 我使用 arcs（G2 和 G3 命令）观察到相同的行为，即使使用最新的固件 100.15。问题似乎出在 TinyG2 控制器的握手协议上。G2 和 G3 命令可能会导致规划器缓冲区的缓冲区溢出，因为这些命令直接填充规划器缓冲区。由于通信协议的描述，我试图修改代码。1) 向控制器发送命令 2) 等待接收 (ack – send as r: 3) 发送下一个命令。这不适用于 arc 命令，因为这些命令用不止一个值填充规划器缓冲区，并且 qr 响应很慢。如果在规划器缓冲区被 G2/G3 命令填满时发送更多命令，控制器会崩溃（？？）我试图围绕这个问题进行编程，但我没有 不知道在运动命令完成时使用控制器的状态报告是否是最佳实施方式。(sr: line: #) 命令将在发送前进行检查并生成行号。如果发送 G2/G3 命令，发送器将等待直到规划器缓冲区有一些可用空间并且运动命令完成。我用一些不同的程序对其进行了测试，看起来相当不错。您会发现修改后的文件作为附件。 最好 阿克塞尔 |
合作者
|
@amx1我将为您的代码做一些测试。非常感谢你的帮助。 |
|
您好， 我测试了示例目录的代码，例如 jsdc.gcode、g2-arc.gcode，…一些示例，如螺旋和 3D 打印代码不起作用，因为命令（E…和 3D 弧） TinyG2 不支持。 最好 阿克塞尔 |
合作者
|
感谢您的信息。我确实遇到了 v100.15 的一些问题，无法弄清楚哪里出了问题。我将使用 v100.17 尝试您的解决方案并及时更新。 |
|
亲爱的 Cheton，我联系了 TinyG2 的开发人员。现在使用 V100.17 和“simple linemode”非常简单，它就像一个魅力。我附上了最新版本。顺便说一句，它不适用于 V100.15。最佳 Axel Von：Rob Giseburt [mailto:notifications@github.com] Gesendet：Sonntag，2017 年 1 月 8 日 02:02 An：synthetos/g2 <g2@noreply.github.com> 抄送：评论 <comment@noreply.github。 com> Betreff：回复：[synthetos/g2] 随机 GCode 行跳过并在循环中间停止。( #209) 我认为我们在发件人方面看到了很多过于复杂的情况。这在很大程度上是由于历史协议与当前协议混淆所致。让我解释。发送到 g2core 机器的最简单方法是简单地发送行。您必须尊重操作系统何时阻塞，但这通常只是您打开缓冲区时的一个设置。我们称之为“爆破”技术。“爆破数据”技术的主要缺点是主机端的缓冲区变大并且您无法发送提要保持。此外，某些主机（尤其是小型 Linux 机器）不能很好地处理大型发送缓冲区，并且使用了比它们应该使用的更多的处理器（可能是在将缓冲区分页到 RAM 或从 RAM 分页时）。因此，发送到 g2core 机器的下一个最简单的方法，也是最简单的具有非常灵敏的进给保持的方法，是：1) 发送一行 2) 等待 {r} 响应 3) 如果有更多行要发送，则转到 1 4) 完成 我们将称之为“简单行模式”。该技术存在一个问题，即某些动作非常简短，传输时间可能比执行时间更长。因此，为了避免在这种情况下出现抖动，我们用几行“准备”频道。四似乎工作得很好。0) 计算您必须发送多少行（IOW，在 gcode 文件中等）并将其放入 lines_in_file 中。设置 lines_to_send=4 1) while (lines_to_send && lines_in_file) { send_next_line(); lines_to_send–; lines_in_file–; } 2) 从串行读取行，计算 {r}s。对于每个 {r}，设置 lines_to_send++。（此处进行错误检查和状态报告处理。） 3) if lines_in_file > 0 the goto (1) 4) done 如果 1 和 2 异步运行，则最好，在不同的线程或事件驱动中，但这不是绝对必要的。我们称之为“整行模式”。请注意，在这些中我们都不关心队列报告（顺便说一句，已弃用），或者我们关心发送的字符等。我确实掩盖了错误处理，它正在解析返回的行，注意 { sr:{stat:…}}，{er:{…}} 中的错误报告，以及响应页脚中的非零状态 {r:…, f:[…,status,. ..]}。非零状态通常是非致命的，可以忽略。如您所见，您无法“耗尽”g2core 接收缓冲区。它只会在主机端备份。我们弃用队列报告 (qr) 只是因为 amx1 所说的一些 gcode 行（如弧线）如何自行填充一个空队列。那里’
On Sat, Jan 7, 2017 at 6:11 PM amx1 ***@***.*** ***@***.***> > wrote: @aldenhart <https://github.com/aldenhart>, @giseburt <https://github.com/giseburt> and all the others working on this, it is the first time I am posting and therefore I would like to thank you all for your amazing work first. Maybe I can also help a bit by providing some experience I made. I have some problems to use chilipeppr because I dont have a permanent internet connection in my workshop and thats why I played a bit with the CNC Software of Cheton Wu (https://github.com/cheton/cnc). The implementation of the TinyG2 protocol in chetons code is not working without problems and I tried to fix it. The update to V100.17 changed the behaviour of the controller very much. It is now working much closer to the described protocol ( “r” handshake aka linemode), but I also saw the errors of dropping lines or even crashing the controller especially with ARC (G2 G3) or S.. or M commands also. You will find my modified subroutines of chetons code in the attachment. Take it as an example for the implemented state engine. The problem for me was, that that the controller sends an {r: ..} always after receiving the command independent of the status of the planner queue which leads to a buffer overflow if you dont check QR. Simple commands and linear moves only generate one entry in the planner queue, but arcs and other commands could generate more entries automatically. Therefore checking the qr state before sending against a “low water mark” only is not sufficient. I implemented a wait state for the “complex” commands which stops the sender until the controller issues the next sr: line report. From my timing log, it seems that the controller sends the sr: line statement when starting the execution of the specific command. It has then enough space for the next arc or linear move, if the planner queue is not filling (qi == 0 or qo > qi). Up to now it is running pretty smooth with all my test cases. The challenge for me is, that the complex buffer chain and the variable reporting makes it very difficult to synch with the controller, if you want to fill the planner queue as much as possible. Chilipeppr was the benchmark for me. The “handshake” behaviour changed significantly from V100.16 to
|
你好。我认为这个程序很棒！
我用了一年，比 chilipeperr.com 的网页更喜欢它，它舒适且视觉上令人愉悦
我现在使用 tinyg2，de 100.x 分支。
我使用 vectric aspire，当我用 arcs、g2 或 g3 生成 gcode 时，tinyg2 冻结或生成错误的弧线。
首先，我认为是 tinyg2 问题，可能是配置问题。我尝试了其他早期版本，但没有解决问题。
但昨天我尝试通过 chilipepperr.com 发送相同的 gcode，然后 woilaa，它工作正常。
当我使用这个程序像这样发送 gcode 时：
程序停止 o 做出糟糕的设计（比如直线而不是弧线）。
有时在一点。有时在其他。
可能问题出在 J 因为，
当我发送这样的代码时：
通过 json 服务器发送 gcode 会不会有问题？
谢谢