注释
你可能有一个错误。Grbl 应该几乎立即执行它收到的任何命令。如果 Grbl 必须快速执行许多非常短的行,它会变慢。这是因为规划器没有足够的距离来加速。查看 repo 中的 stream.py 脚本,了解如何编写一个简单的流媒体。此外,针对 UGS 或 bCNC 等其他 GUI 进行测试以测试性能。 |
在 $C 检查模式下一切正常。在这种模式下,我每秒可以收到超过 400 行,没有错误或延迟。 |
@CliveMcCarthy: 是的,因为检查模式没有任何计划。解析一下。 |
看来,我最多可以将大约 35 行每秒 26 字节的代码从我的代码泵入 Grbl,而规划器(大概)偶尔会在继续之前将事情保持十分之几秒。事情应该是这样吗?我已经运行了 50,000 行 G 代码,运行中最初的不稳定行为似乎已经稳定下来。计划者是否从给出的代码“风格”中“学习”?在 09/08/2017 04:09 PM,Sonny Jeon 写道: @CliveMcCarthy: 是的,因为检查模式没有任何计划。解析一下。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:” https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png” “avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png”,#1284:@CliveMcCarthy:是的,因为检查模式没有任何计划。只需解析。”}],”action”:{“name”:”View Issue”,”url”:” #1284 (comment) “}}}
|
经过更多测试后,我似乎可以平均每秒发送 40 条 G 代码行,每行 1 毫米,即 2,400 毫米/分钟。有长达 12 秒的重复周期性延迟。 |
看来我将不得不等待 ARM 版本:没有多少“团队”Grbl,因为很长一段时间以来都是我自己。v1.0 发布后不久将放弃对 8 位的支持。我将继续投入我所有的时间来继续开发 ARM 版本,这是对 Grbl 基础代码的完全重写。Grbl 本身是专门为 8 位 AVR 设计的,并且有很多“令人讨厌”的代码,这些代码是为了最大限度地提高性能和减少编译的闪存大小而编写的。主要是后者。ARM 版本没有这样的限制,并且有许多算法改进将使其在基本层面上变得更好。我不会透露它们是什么,但它们会很棒。2017 年 9 月 8 日 04 日: @CliveMcCarthy:是的,因为检查模式没有任何计划。解析一下。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:” https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png” ,”avatar_image_url”:”https://cloud.githubusercontent.https://github.com/grbl/grbl”}},”updates”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284:@CliveMcCarthy:是的,因为检查模式没有任何计划。只需解析。”}],”action”:{“name”:”View Issue”,”url”:” #1284 (comment) “}}}
|
您是否按照我的要求进行了测试并针对信誉良好的 GUI 进行了测试?Grbl 每秒可以处理高达 250 行。就像 wiki 页面状态一样,发送和响应协议并不是最快的。如果您需要更快,请使用字符计数协议。 |
我用 UGS 做了一个快速测试,发现它可以在大约一个小时内运行我的测试 G-Code,它有大约 140,000 行。相当满意。我的典型 G 代码行(30 字节)的典型写入从我的代码中花费不到 10 微秒。如果我运行我的测试 G 代码,在我的程序和检查模式打开的情况下,来自 Grbl 的响应通常需要不到 10 微秒,但通常也需要 4,000 微秒。真的很奇怪,因为这些行非常相似,并且人们会期望解析的时间几乎是恒定的。写入和确认循环时间足够快,它让我相信我的计算机和 Arduino 之间的硬件/软件协议运行正常。如果我在操作模式下运行它,速度会很慢。3 字节读取响应的时间(Grbl 的“ok”确认)与返回的速度相差很大,通常为 5 毫秒,通常为 20 毫秒,但通常为 100 毫秒和周期性的多秒。我尝试在读取发生之前在写入之后添加延迟,但它并没有改善缓慢的响应。如果写和确认的周期时间是一致的 25 毫秒,它将大约等于 UGS 的周期时间。这很奇怪。Sonny Jeon 在 2017 年 9 月 9 日晚上 9:52 写道:您是否按照我的要求进行了测试并针对信誉良好的 GUI 进行了测试?— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284 : 你有没有按照我的要求做并针对有信誉的 GUI 进行测试?”}],”action”:{ “name”:”查看问题”,”url”:” #1284 (comment) “}}}
|
此屏幕截图很好地说明了这些问题。序列结束时有一条 M08 指令,Grbl 需要 24 秒才能响应。在 2017 年 9 月 9 日晚上 9:52,Sonny Jeon 写道: 你有没有按照我的要求做,并针对有信誉的 GUI 进行测试?— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284 : 你有没有按照我的要求做并针对有信誉的 GUI 进行测试?”}],”action”:{ “name”:”查看问题”,”url”:” #1284 (comment) “}}}
|
将您的 $1 设置为 $1=255。Grbl 每秒可以处理多达 400 行。这是每行 2.5 毫秒。不是 25. 机器可能会停止,强制执行步骤延迟,然后恢复。默认值约为 25 毫秒,这可以解释您的问题 |
您看到的较长延迟来自您的 g 代码。Grbl 必须在执行需要与运动同步的行之前执行所有缓冲的运动。M8 M9 M30 等都可以作为同步命令。延迟来自等待完成排队的运动。 |
这似乎有很大帮助。进给率变化是否也算作“与运动同步”,因为每次进给率变化似乎也会导致“失速”?还有其他看似与任何东西无关的“摊位”……顺便说一句,感谢您对此的帮助。2017 年 9 月 11 日上午 8:52,Sonny Jeon 写道:将您的 1 美元设置设置为 1 美元=255。Grbl 每秒可以处理多达 400 行。这是每行 2.5 毫秒。不是 25. 机器可能会停止,强制执行步骤延迟,然后恢复。默认值约为 25 毫秒,这可以解释您的问题 – 您收到此消息是因为您被提及。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284:将 $1 设置为 $1=255。Grbl 每秒可以处理多达 400 行。这是每行 2.5 毫秒。不是 25. 机器可能会停止,强制执行步骤延迟,然后恢复。默认值约为 25 毫秒,这可以解释您的问题\r\n”}],”action”:{“name”:”
|
您还有其他 Grbl 建议吗?我每行仍然只有不到 20 毫秒。2017 年 9 月 11 日上午 8:52,Sonny Jeon 写道:将您的 1 美元设置设置为 1 美元=255。Grbl 每秒可以处理多达 400 行。这是每行 2.5 毫秒。不是 25. 机器可能会停止,强制执行步骤延迟,然后恢复。默认值约为 25 毫秒,这可以解释您的问题 – 您收到此消息是因为您被提及。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284:将 $1 设置为 $1=255。Grbl 每秒可以处理多达 400 行。这是每行 2.5 毫秒。不是 25. 机器可能会停止,强制执行步骤延迟,然后恢复。默认值约为 25 毫秒,这可以解释您的问题\r\n”}],”action”:{“name”:”
|
我的代码计算了响应时间的运行平均值。在 60,000 行之后,平均为 10.8 毫秒。2017 年 9 月 11 日上午 9:00,Sonny Jeon 写道:您看到的延迟时间越长,来自您的 g 代码。Grbl 必须在执行需要与运动同步的行之前执行所有缓冲的运动。M8 M9 M30 等都可以作为同步命令。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284:您看到的延迟越长,来自您的 g 代码。Grbl 必须在执行需要与运动同步的行之前执行所有缓冲的运动。M8 M9 M30 等都符合同步命令的条件。”}],”action”:{“name”:”View Issue”,”url”:”
|
你还在使用发送响应协议吗?如果是这样,请使用 UGS 或 GRBL stream.py 脚本再次测试。他们使用字符计数协议。 |
是的,我仍在使用发送响应协议。我最近一次以 1=255 美元的价格运行,情况有了很大改善。以前在 UGS 或我的代码上大约 140,000 行需要 80 分钟,它们是相同的。现在该作业在我的代码上运行 50 分钟,但是 Grbl 的平均响应时间为 13.6 毫秒。我的代码在约 5 微秒内发送一行代码,因此只要 Grbl 需要另一行,它就在那里(C 代码将比 Python 或 Java 快得多)。我所有的 G 代码行都非常接近相同的大小:27 到 30 个字节。我想我可以用三四行预加载 127 字节的输入缓冲区,而不是等待确认。然后一次进行一行。当规划器完成一行时,Grbl 是否发送确认,或者输入缓冲区是否确认收到一行?2017 年 9 月 11 日上午 11:21,Sonny Jeon 写道:您还在使用发送响应协议吗?如果是这样,请使用 UGS 或 GRBL stream.py 脚本再次测试。他们使用字符计数协议。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”副标题”:”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284 : 你还在使用发送响应协议吗?如果是这样,请使用 UGS 或 GRBL stream.py 脚本再次测试。他们使用字符计数协议。”}],”action”:{“name”:”查看问题”,”url”:” #1284 (comment) “}}}
|
我进行了 140,000 行测试,并在 UGS 上以 1=255 美元的价格运行它。运行时间为 50 分钟。我的代码的运行时间是 49.8 分钟。我得出的结论是字符计数有助于 Java 发送者,但是,我的愚蠢发送和确认可能会通过 C 程序的更快馈送得到补偿,这使管道保持满。UGS 也经历了一些停滞,但当然,我没有数字,只是视觉印象。再过一周,我将能够使用当前的驱动程序和软件在我们的 CNC 机器上运行这个 140,000 行测试。然后我会知道我是否可以将硬件切换到 Arduino 和 Grbl。我希望我可以,因为我不喜欢使用 XP 和传统的并行端口接口。2017 年 9 月 11 日上午 11:21,Sonny Jeon 写道: 你还在使用发送响应协议吗?如果是这样,请使用 UGS 或 GRBL stream.py 脚本再次测试。他们使用字符计数协议。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:” 他们使用字符计数协议。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:” 他们使用字符计数协议。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284 : 你还在使用发送响应协议吗?如果是这样,请使用 UGS 或 GRBL stream.py 脚本再次测试。他们使用字符计数协议。”}],”action”:{“name”:”查看问题”,”url”:” #1284 (comment) “}}}
|
我的代码以非常大的 G 代码文件在稳定的条件下驱动 Grbl。它已经持续运行了八个多小时,还有六个小时的时间。 似乎 Grbl 每隔 100~120 行左右就停止一次。我的代码发送一个“?” 每 20 行请求一次状态,并且计划缓冲区(除少数例外)报告 17 次——它总是满的——甚至在停顿之前也是如此。 停顿的特点是读取响应时间超过一秒。正常响应时间不到 20 毫秒。 |
我今天早上的第一个实验是将结偏差从 0.02mm 增加到 1mm,这似乎减少了失速的数量。我现在将任何 100 毫秒或更长的响应视为停顿。绝大多数都在 20 毫秒以下。 |
编译后的 C 可执行文件比 Python 或 Java 快已经不是什么秘密了。您的 GUI 的延迟很低,我并不感到惊讶。 我开始觉得我在一遍又一遍地重复自己。这是浪费时间和精力。请考虑字符计数协议。正如 wiki 界面页面所述,它效率更高,可以加快工作速度,建议用于要求更高的工作。主要原因是您没有考虑将串行消息传输到 Grbl 所需的时间。对于 115200 波特的 25 个字符,大约是 2.2 毫秒。Grbl 必须等到它收到完整的消息后才能解析并执行它。另外,请考虑 Grbl 将“ok”传输回您的 GUI 所需的时间。尽管时间更短,Grbl 可以立即开始执行下一行,然后再传输“ok”和 USB 协议 + 主机的延迟时间。 请尝试了解 Grbl 的工作原理,然后再对其进行“表演”时间。Grbl 有一个 15 块左右的规划器。它在规划器内的总距离内规划最佳加速和执行时间。如果这些块都是很短的线,那么它里面没有那么多的距离或时间。如果您的加速度很低,那么它在必须减速到缓冲区末端停止之前无法加速到高速,以始终确保始终管理运动。这些因素,包括路口偏差(改变它通过路口的速度),都会影响 Grbl 的性能,但与沟通没有太大关系。这是您的设置、规划器大小和规划器假设的限制。 至于您的 1 秒读取响应问题,很难说出您定义为 1 秒的内容。我认为您需要分享您的 $$ 设置、您的 $I 构建信息字符串和您的测试程序。因此,我可以看到您正在尝试做什么,并帮助确定主要问题是什么。 |
我刚刚尝试向您发送测试代码,但文件为 7.5MB,超出了 Github 电子邮件服务器的限制。来自远程服务器的响应是:552 5.3.4 消息大小超过固定限制 在 09/12/2017 08:16 AM,Sonny Jeon 写道:编译的 C 可执行文件比 Python 或 Java 更快并不是什么秘密。您的 GUI 的延迟很低,我并不感到惊讶。我开始觉得我在一遍又一遍地重复自己。这是浪费时间和精力。请考虑字符计数协议。正如 wiki 界面页面所述,它效率更高,可以加快工作速度,建议用于要求更高的工作。主要原因是你没有 t 考虑了将串行消息传输到 Grbl 所需的时间。对于 115200 波特的 25 个字符,大约是 2.2 毫秒。Grbl 必须等到它收到完整的消息后才能解析并执行它。另外,请考虑 Grbl 将“ok”传输回您的 GUI 所需的时间。尽管时间更短,Grbl 可以立即开始执行下一行,然后再传输“ok”和 USB 协议 + 主机的延迟时间。请尝试了解 Grbl 的工作原理,然后再对其进行“表演”时间。Grbl 有一个 15 块左右的规划器。它在规划器内的总距离内规划最佳加速和执行时间。如果这些块都是很短的线,那么它里面没有那么多的距离或时间。如果您的加速度很低,那么它在必须减速到缓冲区末端停止之前无法加速到高速,以始终确保始终管理运动。这些因素,包括路口偏差(改变它通过路口的速度),都会影响 Grbl 的性能,但与沟通没有太大关系。这是您的设置、规划器大小和规划器假设的限制。至于您的 1 秒读取响应问题,很难说出您定义为 1 秒的内容。我认为您需要分享您的 $$ 设置、您的 $I 构建信息字符串和您的测试程序。因此,我可以看到您正在尝试做什么,并帮助确定主要问题是什么。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284: 编译后的 C 可执行文件比 Python 或 Java 快已经不是什么秘密了。您的 GUI 的延迟很低,我并不感到惊讶。\r\n\r\n我开始觉得我在一遍又一遍地重复自己。这是浪费时间和精力。请考虑字符计数协议。正如 wiki 界面页面所述,它效率更高,可以加快工作速度,建议用于要求更高的工作。主要原因是您没有考虑将串行消息传输到 Grbl 所需的时间。对于 115200 波特的 25 个字符,大约是 2.2 毫秒。Grbl 必须等到它收到完整的消息后才能解析并执行它。另外,请考虑 Grbl 将“ok”传输回您的 GUI 所需的时间。虽然时间更短,Grbl 可以在传输“ok”和 USB 协议的延迟时间 + 您的主机之前立即开始执行下一行。\r\n\r\n请在放置“性能”时间之前尝试了解 Grbl 的工作原理在上面。Grbl 有一个 15 块左右的规划器。它在规划器内的总距离内规划最佳加速和执行时间。如果这些块都是很短的线,那么它里面没有那么多的距离或时间。如果您的加速度很低,那么它在必须减速到缓冲区末端停止之前无法加速到高速,以始终确保始终管理运动。这些因素,包括路口偏差(改变它通过路口的速度),都会影响 Grbl 的性能,但与沟通没有太大关系。这是您的设置、计划器大小和计划器假设的限制。\r\n\r\n就您的 1 秒读取响应问题而言,很难说出您将 1 秒定义为什么。我认为您需要分享您的 $$ 设置、您的 $I 构建信息字符串和您的测试程序。所以我可以看到你正在尝试做什么,并帮助确定主要问题是什么。”}],”action”:{“name”:”View Issue”,”url”:”#1284(评论) “}}}
|
|
您超过了 Grbl 支持的最大 30kHz 步进速率。(15,000 毫米/分钟 *250 步/毫米)/60 秒/分钟 -> 62.5 kHz。Grbl 不会主动对此进行检查,因为 v1.1 中没有任何闪存空间。所有剩余的字节都保留用于错误修复。 |
真的很小 在 09/12/2017 08:16 AM,Sonny Jeon 写道: 编译的 C 可执行文件比 Python 或 Java 更快已经不是什么秘密了。您的 GUI 的延迟很低,我并不感到惊讶。我开始觉得我在一遍又一遍地重复自己。这是浪费时间和精力。请考虑字符计数协议。正如 wiki 界面页面所述,它效率更高,可以加快工作速度,建议用于要求更高的工作。主要原因是您没有考虑将串行消息传输到 Grbl 所需的时间。对于 115200 波特的 25 个字符,大约是 2.2 毫秒。Grbl 必须等到它收到完整的消息后才能解析并执行它。另外,请考虑 Grbl 将“ok”传输回您的 GUI 所需的时间。尽管时间更短,Grbl 可以立即开始执行下一行,然后再传输“ok”和 USB 协议 + 主机的延迟时间。请尝试了解 Grbl 的工作原理,然后再对其进行“表演”时间。Grbl 有一个 15 块左右的规划器。它在规划器内的总距离内规划最佳加速和执行时间。如果这些块都是很短的线,那么它里面没有那么多的距离或时间。如果你的加速度很低,那么它可以’ t 在必须减速到缓冲区结束处停止之前加速到高速,以始终确保始终管理运动。这些因素,包括路口偏差(改变它通过路口的速度),都会影响 Grbl 的性能,但与沟通没有太大关系。这是您的设置、规划器大小和规划器假设的限制。至于您的 1 秒读取响应问题,很难说出您定义为 1 秒的内容。我认为您需要分享您的 $$ 设置、您的 $I 构建信息字符串和您的测试程序。因此,我可以看到您正在尝试做什么,并帮助确定主要问题是什么。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284: 编译后的 C 可执行文件比 Python 或 Java 快已经不是什么秘密了。您的 GUI 的延迟很低,我并不感到惊讶。\r\n\r\n我开始觉得我在一遍又一遍地重复自己。这是浪费时间和精力。请考虑字符计数协议。正如 wiki 界面页面所述,它效率更高,可以加快工作速度,建议用于要求更高的工作。主要原因是您没有考虑将串行消息传输到 Grbl 所需的时间。对于 115200 波特的 25 个字符,大约是 2.2 毫秒。Grbl 必须等到它收到完整的消息后才能解析并执行它。另外,请考虑 Grbl 将“ok”传输回您的 GUI 所需的时间。虽然时间更短,Grbl 可以在传输“ok”和 USB 协议的延迟时间 + 您的主机之前立即开始执行下一行。\r\n\r\n请在放置“性能”时间之前尝试了解 Grbl 的工作原理在上面。Grbl 有一个 15 块左右的规划器。它在规划器内的总距离内规划最佳加速和执行时间。如果这些块都是很短的线,那么它里面没有那么多的距离或时间。如果您的加速度很低,那么它在必须减速到缓冲区末端停止之前无法加速到高速,以始终确保始终管理运动。这些因素,包括路口偏差(改变它通过路口的速度),都会影响 Grbl 的性能,但与沟通没有太大关系。这是您的设置、计划器大小和计划器假设的限制。\r\n\r\n就您的 1 秒读取响应问题而言,很难说出您将 1 秒定义为什么。我认为您需要分享您的 $$ 设置、您的 $I 构建信息字符串和您的测试程序。所以我可以看到你正在尝试做什么,并帮助确定主要问题是什么。”}],”action”:{“name”:”View Issue”,”url”:”#1284(评论) “}}}
|
UGS中使用了字符计数协议,对吗?当我在 UGS 上运行测试代码时,它会与我的代码同时完成工作。字符计数将无济于事。在 2017 年 9 月 12 日上午 8 点 16 分,Sonny Jeon 写道: 编译的 C 可执行文件比 Python 或 Java 更快已经不是什么秘密了。您的 GUI 的延迟很低,我并不感到惊讶。我开始觉得我在一遍又一遍地重复自己。这是浪费时间和精力。请考虑字符计数协议。正如 wiki 界面页面所述,它效率更高,可以加快工作速度,建议用于要求更高的工作。主要原因是你没有 t 考虑了将串行消息传输到 Grbl 所需的时间。对于 115200 波特的 25 个字符,大约是 2.2 毫秒。Grbl 必须等到它收到完整的消息后才能解析并执行它。另外,请考虑 Grbl 将“ok”传输回您的 GUI 所需的时间。尽管时间更短,Grbl 可以立即开始执行下一行,然后再传输“ok”和 USB 协议 + 主机的延迟时间。请尝试了解 Grbl 的工作原理,然后再对其进行“表演”时间。Grbl 有一个 15 块左右的规划器。它在规划器内的总距离内规划最佳加速和执行时间。如果这些块都是很短的线,那么它里面没有那么多的距离或时间。如果您的加速度很低,那么它在必须减速到缓冲区末端停止之前无法加速到高速,以始终确保始终管理运动。这些因素,包括路口偏差(改变它通过路口的速度),都会影响 Grbl 的性能,但与沟通没有太大关系。这是您的设置、规划器大小和规划器假设的限制。至于您的 1 秒读取响应问题,很难说出您定义为 1 秒的内容。我认为您需要分享您的 $$ 设置、您的 $I 构建信息字符串和您的测试程序。因此,我可以看到您正在尝试做什么,并帮助确定主要问题是什么。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284: 编译后的 C 可执行文件比 Python 或 Java 快已经不是什么秘密了。您的 GUI 的延迟很低,我并不感到惊讶。\r\n\r\n我开始觉得我在一遍又一遍地重复自己。这是浪费时间和精力。请考虑字符计数协议。正如 wiki 界面页面所述,它效率更高,可以加快工作速度,建议用于要求更高的工作。主要原因是您没有考虑将串行消息传输到 Grbl 所需的时间。对于 115200 波特的 25 个字符,大约是 2.2 毫秒。Grbl 必须等到它收到完整的消息后才能解析并执行它。另外,请考虑 Grbl 将“ok”传输回您的 GUI 所需的时间。虽然时间更短,Grbl 可以在传输“ok”和 USB 协议的延迟时间 + 您的主机之前立即开始执行下一行。\r\n\r\n请在放置“性能”时间之前尝试了解 Grbl 的工作原理在上面。Grbl 有一个 15 块左右的规划器。它在规划器内的总距离内规划最佳加速和执行时间。如果这些块都是很短的线,那么它里面没有那么多的距离或时间。如果您的加速度很低,那么它在必须减速到缓冲区末端停止之前无法加速到高速,以始终确保始终管理运动。这些因素,包括路口偏差(改变它通过路口的速度),都会影响 Grbl 的性能,但与沟通没有太大关系。这是您的设置、计划器大小和计划器假设的限制。\r\n\r\n就您的 1 秒读取响应问题而言,很难说出您将 1 秒定义为什么。我认为您需要分享您的 $$ 设置、您的 $I 构建信息字符串和您的测试程序。所以我可以看到你正在尝试做什么,并帮助确定主要问题是什么。”}],”action”:{“name”:”View Issue”,”url”:”#1284(评论) “}}}
|
不确定您是否收到我的回复,但问题是您超过了 Grbl 支持的 30kHz 最大步进速率。这会导致您的 Arduino 冻结并可能崩溃。Arduino 的所有时间都花在维修步进脉冲而不是计划上。将您的步长/毫米减少到更真实的值,例如 40 步/毫米到 80 步/毫米。 |
|
我已经做了。我将其设置为 50 步/毫米。Arduino 没有崩溃。我仍然从 Grbl 获得摊位,但更少。还有什么我应该放松的吗?$1=255 (step idle delay, ms) $2=0 (step port invert mask:00000000) $3=0 (dir port invert mask:00000000) $4=0 (step enable invert, bool) $5=0 (limit pins invert, bool) $6=0 (probe pin invert, bool) $10=12 (status report mask:00001100) $11=1.000 (junction deviation, mm) $12=1.000 (arc tolerance, mm) $13=0 (report inches, bool) $20 =0(软限制,布尔值)$21=0(硬限制,布尔值)$22=0(归位周期,布尔值)$23=0(归位目录反转掩码:00000000)$24=25.000(归位进给,毫米/分钟)$25= 500.000(归位搜索,mm/min) $26=250 (homing debounce, msec) $27=1.000 (homing pull-off, mm) $100=50.000 (x, step/mm) $101=50.000 (y, step/mm) $102=250.000 (z, step/mm) $110=5000.000 (x max rate, mm/min) $111=5000.000 (y max rate, mm/min) $112=4000.000 (z max rate, mm/min) $120=500.000 (x accel, mm/sec ^2) $121=500.000 (y 加速度, mm/sec^2) $122=10.000 (z 加速度, mm/sec^2) $130=1200.000 (x 最大行程, mm) $131=1000.000 (y 最大行程, mm) $132 =200.000 (z max travel, mm) ok On 09/12/2017 09:20 AM,Sonny Jeon 写道: 不确定您是否收到我的回复,但问题是您超过了 Grbl 支持的最大 30kHz 步进速率。这会导致您的 Arduino 冻结并可能崩溃。所有的阿杜诺 s 时间花在服务阶跃脉冲而不是计划上。将您的步长/毫米减少到更真实的值,例如 40 步/毫米到 80 步/毫米。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:” — 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:” — 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284 : 不确定您是否收到我的回复,但问题是您超过了 Grbl 支持的最大 30kHz 步骤速度。这会导致您的 Arduino 冻结并可能崩溃。Arduino 的所有时间都花在维修步进脉冲而不是计划上。“}}}
|
重新测试UGS。 |
会做。我刚刚运行了我发送给您的名为 hello_image_small.cnc 的文件——它在 14.12 分钟内使用这些 Grbl 设置在我的代码上运行。我不得不大大减小图纸尺寸以减小文件大小,以便我可以将其发送给您。在 09/12/2017 09:43 AM,Sonny Jeon 写道:重新测试 UGS。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284 : 重新测试 UGS。”}],”action”:{“name”:”查看问题” “url”:” #1284 (评论) “}}}
|
UGS 结果为 14.5 分钟。所以结果是一样的。UGS上的摊位也很明显。在 09/12/2017 09:43 AM,Sonny Jeon 写道:重新测试 UGS。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:” https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png” “在 GitHub”,”url”:” https://github.com/grbl/grbl”}},”updates”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit在#1284 : 重新测试 UGS。”}],”action”:{“name”:”View Issue”,”url”:” #1284 (comment) “}}}
|
@CliveMcCarthy看你的画很有趣。你介意把你的文件发给我吗?我可以在 STM32 端口以及我的 Windows 模拟上尝试它,看看我是否能找到一些东西。 |
您可能会发现这个低级 C 代码对于测试未来的 Grbl 版本很有用。在 09/12/2017 09:43 AM,Sonny Jeon 写道:重新测试 UGS。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:” https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png” “头像_图片网址”:”https://cloud.https://github.com/grbl/grbl”}},”updates”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284:重新测试 UGS。 “}],”action”:{“name”:”查看问题”,”url”:” #1284 (comment) “}}}
|
恐怕我们实际图纸的 G 代码文件太大而无法通过 Github 发送。我发送给 Sonny 的小测试文件展示了我在 Arduino 上使用 Grbl 时遇到的问题。您的 STM32 端口与 Arduino 上的 Grbl 兼容吗?2017 年 9 月 12 日上午 10:14,usbcnc 写道: @CliveMcCarthy看你的画很有趣。你介意把你的文件发给我吗?我可以在 STM32 端口以及我的 Windows 模拟上尝试它,看看我是否能找到一些东西。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:” https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png” “头像_图片网址”:https://github.com/grbl/grbl”}},”updates”:{“snippets”:[{“icon”:”PERSON”,”message”:”@usbcnc in #1284 : @CliveMcCarthy 很有趣你的画。你介意把你的文件发给我吗?我可以在 STM32 端口以及我的 Windows 模拟上尝试它,看看是否能找到一些东西。”}],”action”:{“name”:”View Issue”,”url”:” #1284(评论) “}}}
|
我没有收到任何文件。重命名为 .txt 并拖放到您的 github 响应中。 |
会在下午早些时候做。
|
我可以给你发其他图纸文件。你看到的是限量版的一部分。
|
如果你不想公开分享任何东西,你可以给我发电子邮件。 |
这有我对 Grbl 的低级接口。没有什么特别的,只是它确实试图测量传输速度。它可能需要一些工作才能在 Windows 上运行,但对于 Linux 来说会很好。 |
不,我的意思是分享您正在测试的 g 代码文件。这就是我需要查看问题与 Grbl 相关的全部内容。 |
行,可以。这是在 14 分钟内运行的文件。 |
这是USBCNC可以尝试的大图。天使.cnc.gz |
测试文件没有任何秘密。如果你在 UGS 上运行它并进行可视化,你就会明白为什么!2017 年 9 月 12 日下午 12:35,Sonny Jeon 写道:不,我的意思是分享您正在测试的 g 代码文件。这就是我需要查看问题与 Grbl 相关的全部内容。— 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“external_key”:”github/grbl/grbl”,”title “:”grbl/grbl”,”subtitle”:”GitHub 存储库”,”main_image_url”:”https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284:不,我的意思是分享您正在测试的 g 代码文件。这就是我需要查看问题与 Grbl 相关的全部内容。”}],”action”:{“name”:”查看问题”,”url”:” #1284 (comment) “}}}
|
@CliveMcCarthy:在您的 g 代码程序中的任何地方都没有性能问题。我只是用 stream.py 脚本和 Grbl v1.1(在性能方面与 v0.9 基本相同)对其进行了测试。Grbl 完全按照它应该运行的方式运行它。去ARM不会有什么不同。让我来告诉你为什么。 您已经在整个程序中组合了编程的 3 轴运动。与 10000mm/s^2 和 500mm/s^2 的 x 和 y 轴相比(在您的缩减设置中),您的 Z 轴加速度非常小,为 $122=10.00。你认为是停滞的,不是停滞的。它是 Grbl 故意放慢速度并确保不超过 z 轴加速度限制。 UGS 和你的 GUI 程序导致同时出现的原因是这个程序要求不高。当我说要求时,是指每秒有 400 条线,每条线长约 0.1 毫米。这是激光雕刻的常见问题(请注意,Grbl LPC 端口每秒可以处理约 1300 行)。 如果您希望我以更快的进给速度对您的第一个测试进行测试,您需要上传该文件或至少一个类似的文件,以便我可以比较执行时间(使用您的旧设置,除了您的步长/毫米全部为 50.0) . |
啊!好的!我正在运行我的测试,所有三个轴都设置相同。直到下周我才知道我的机器实际上能做什么。在 09/12/2017 01:04 PM,Sonny Jeon 写道: @CliveMcCarthy:在您的 g 代码程序中的任何地方都没有性能问题。我只是用 stream.py 脚本和 Grbl v1.1(在性能方面与 v0.9 基本相同)对其进行了测试。Grbl 完全按照它应该运行的方式运行它。去ARM不会有什么不同。让我来告诉你为什么。您已经在整个程序中组合了编程的 3 轴运动。与 10000mm/s^2 和 500mm/s^2 的 x 和 y 轴相比(在您的缩减设置中),您的 Z 轴加速度非常小,为 $122=10.00。你认为是停滞的,不是停滞的。它是 Grbl 故意放慢速度并确保不超过 z 轴加速度限制。UGS 和你的 GUI 程序导致同时出现的原因是这个程序不是 要求很高。当我说要求时,是指每秒有 400 条线,每条线长约 0.1 毫米。这是激光雕刻的常见问题(请注意,Grbl LPC 端口每秒可以处理约 1300 行)。如果您希望我以更快的进给速度对您的第一个测试进行测试,您需要上传该文件或至少一个类似的文件,以便我可以比较执行时间(使用您的旧设置,除了您的步长/毫米全部为 50.0) . — 你收到这个是因为你被提及了。直接回复此电子邮件,在 GitHub 上查看它,或将线程静音。{“api_version”:”1.0″,”publisher”:{“api_key”:”05dde50f1d1a384dd78767c55493e4bb”,”name”:”GitHub”},”entity”:{“https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png”,”avatar_image_url”:”https://cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png”,”action”:{“name”:”在 GitHub 中打开”,”url”:” https://github.com/grbl/grbl “}},”更新”:{“snippets”:[{“icon”:”PERSON”,”message”:”@chamnit in #1284 : @CliveMcCarthy:在您的 g 代码程序中的任何地方都没有性能问题。我只是用 stream.py 脚本和 Grbl v1.1(在性能方面与 v0.9 基本相同)对其进行了测试。Grbl 完全按照它应该运行的方式运行它。去ARM不会有什么不同。让我来告诉你为什么。\r\n\r\n您已经在整个程序中组合了 3 轴运动。与 10000mm/s^2 和 500mm/s^2 的 x 和 y 轴相比(在您的缩减设置中),您的 Z 轴加速度非常小,为 $122=10.00。你认为是停滞的,不是停滞的。是Grbl故意放慢速度,确保不超过z轴加速度限制。\r\n\r\nUGS和你的GUI程序导致同时出现的原因是这个程序要求不高。当我说要求时,即每秒有 400 条线,每条线长约 0.1 毫米。这是激光雕刻的常见问题(请注意,Grbl LPC 端口每秒可以处理大约 1300 行)。\r\n\r\n如果您希望我针对您的第一个测试进行测试,并且进给速度更快,您需要上传该文件或至少一个我可以比较执行时间的类似文件(使用您的旧设置,除了您的步长/mm 全部为 50.0)。\r\n”}],”action”:{“name”:”View问题”,”网址”:”#1284(评论) “}}}
|
顺便说一句,谢谢?
|
@CliveMcCarthy 我在 STM32F103 GRBL 上运行 angel.cnc 3:19,完全没有问题。(18xxxx 行)。 |
克莱夫麦卡锡 评论 on 9 Sep 2017 •
我正在用 Linux 上的 GTK+3.0 在 C 中为 Grbl 编写一个 GUI。它是一个比其他 GUI 更简单的界面,因为我们的工作是 2D 的,具有适度的 Z 要求(绘图仪上的大型艺术图纸)。我正在使用带有规范协议的串行端口和 Grbl 0.9j 的简单发送和确认接口
大多数 G 代码指令的距离都很短~1mm,而且有很多。我发现大多数 G 代码行执行速度非常快(不到 100 毫秒),但有些,特别是在启动时,需要几秒钟。有时可能需要 Grbl 12 秒才能响应 G 代码行。
这是可以预料的还是我有错误?测量,运行 10,000 行 G 代码,我每秒处理大约 13 行。G 代码的进给速度设置为 6,000 毫米/分钟。
以下是串行接口的低级代码:
`
#include “common_header.h”
#include “Arduino_serial_interface.h”
布尔 Grbl_is_connected = 假;
静态int fd;
void show_terminal_options(struct termios *terminal_options)
{
printf(“————————————– ————————\n”);
// — 控制终端输入的选项 — c_iflag
if(terminal_options->c_iflag & ICRNL) printf(“\ttranslate CR to NL on input\n”);
if(terminal_options->c_iflag & IXON) printf(“\tEnable XON/XOFF flow control on output.\n”);
if(terminal_options->c_iflag & IXOFF) printf(“\tEnable XON/XOFF flow control on input.\n”);
if(terminal_options->c_iflag & IXANY) printf(“\t键入任何字符将重新启动停止的输出。(\n”);
if(terminal_options->c_iflag & IGNBRK) printf(“\t忽略输入的中断条件。\n” );
if(terminal_options->c_iflag & BRKINT) printf(“\t如果设置了 IGNBRK,则忽略 BREAK。如果未设置但\n”);
if(terminal_options->c_iflag & IGNPAR) printf(“\tignore 成帧错误和奇偶校验错误。\n”);
if(terminal_options->c_iflag & PARMRK) printf(“\t如果该位被设置,输入字节有奇偶校验或帧错误\n”);
if(terminal_options->c_iflag & INPCK) printf(“\t启用输入奇偶校验。\n”);
if(terminal_options->c_iflag & ISTRIP) printf(“\t去掉第八位。\n”);
if(terminal_options->c_iflag & INLCR) printf(“\ttranslate NL to CR on input.\n”);
if(terminal_options->c_iflag & IGNCR) printf(“\tignore 输入时回车。\n”);
if(terminal_options->c_iflag & IUTF8) printf(“\tcharacter-erase 在熟模式下正确执行。\n”);
}
double compute_task_milli_seconds(struct timeval *start_time)
{
double elapsed_time;
结构 timeval end_time;
}
int write_arduino(char *g_code)
{
int n;
}
int read_arduino(char *response)
{
struct timeval start_time;
双毫秒;
诠释 n = 0;
}
int initialize_serial_port(const char *serial_port)
{
char Ctrl_X_Reset_Grbl[] = {CTRL_X, ‘\n’, ‘\0’};
结构 termios 终端选项;
布尔确定 = 假;
}
`