注释
做了更多的工作,现在有了第一个罐头循环。第一个是 G81 钻孔循环,此时它只对 G90 有效,但它是一个开始。 这是 grbl 使用 G81 钻孔循环运行我的铣床以空气钻 5 个孔的视频。代码如下: G90G20G54 |
@109JB: 这是太棒了。您是否更新了 LinuxCNC 以查看他们的新轨迹规划器是否比本次测试中表现更好? |
我还没有将我的 LinuxCNC 安装升级到新的。它还没有“正式”发布,而且我的 cpu 在我的谷仓里,我还没有互联网,这使得现在升级有点问题。话虽如此,安装了新规划器的 linuxcCNC 用户使用相同的步进器设置运行相同的 G 代码文件,并在 2.6 和 2.7 上获得相同的 5:35 分钟,而新规划器获得了 3:10 分钟。所以,LinuxCNC 中的新规划器确实有很大的不同。 话虽如此,我一直在尽可能地使用我的 GUI,我决定改变我的方法有几个原因。首先,对于固定循环的完整实现,GUI 必须跟踪一堆东西以支持 G98/G99 和 G90/G91 之类的东西。接下来是工具更换,也需要更多的工作。我也有未来实施 G40-G42 的想法,刀具补偿,这将需要更多地跟踪模态值、坐标等。主要的事情是必须为 CDC 至少提前一步,所以我写了我的 GUI 将来会支持这些功能。 所有这些都需要计算时间,因此它延长了循环时间。我的 GUI 现在可以进行前瞻,并完全解析每一行,并支持固定循环 G81、G82、G83、G85、G86 和 G89,完全支持 G98/G99 和 G90/G91,但循环时间增加了。在甚至不使用固定循环(仅 G0/G1 移动)的 Roadrunner 程序中,循环时间约为 3:50,而没有前瞻或固定循环支持的循环时间约为 3:00。一个原因是它在前一行完成之前不会开始处理一行。 它仍然比 LinuxCNC 2.6 的周期时间好很多,但是为了尝试优化,我正在重新编写代码以尝试利用可用的多线程功能。沿着这条路径,我有一个基本实现,它在 3:04 的循环时间内运行 roadrunner 代码,而没有启用固定循环或前瞻。这是从开始到 GRBL 完成其缓冲区中所有内容的实际循环时间。循环计时器在运行结束时等待“空闲”状态,并使用该时间点计算循环时间。 我还稍微更改了 GUI,使其更大一点,以便更容易实现触摸屏。我一直在用旧的 android 平板电脑玩远程桌面,它工作正常,但我以前版本的小按钮让它很难。这个新界面是 1024 x 600 以支持在 10″ 上网本上使用。我是小型平台笔记本电脑/上网本的忠实粉丝,而其他一些 GUI 太大而无法在它们上使用。我有一个 10″ 上网本我已经添加了一个触摸屏,它本来是完美的,但我大约一年前卖掉了它。 有些人给我发了这样的消息,大意是“既然 CAM 可以处理固定循环,为什么还要麻烦它”。如果您总是使用 CAM,这是正确的,但我仍然倾向于使用我的铣床作为伪手动铣床,大量使用 MDI 来运行它。能够键入固定循环意味着与许多代码相比,只有一行代码。特别是如果您开始研究啄钻多个孔。 这是我的新界面,它具有以下更新功能
|
感人的。 我还要几个月的时间才能把我的店开好,六月底才搬进房子。与此同时,自 2014 年 11 月以来遭受严重的机械加工退出! 与此同时,我非常乐意帮助提供编码建议,我的(屏蔽的)电子邮件列在我的用户名下。 格里特 |
谢谢。我很想得到帮助,但我是那些不知道要问什么的业余程序员之一。我知道您可能会嘲笑我的代码,因为我知道有些事情我正在做与最佳实践相反的事情。不过,我学到了很多东西,一旦我学到了一些东西,我就会尝试在整个程序中回过头来纠正这些东西。 我同意串行 IO 事件是驱动大部分周期时间的原因。我今天早些时候在玩我的第一个版本程序,并注意到 GRBL 规划器缓冲区大部分时间几乎是空的,而当在固定循环和前瞻活动的情况下运行时,读取缓冲区基本上一直是空的。因此,我修改了几行以使它们停止运行,然后规划器缓冲区在运行期间保持更满,并且周期时间减少了很多。这让我认为,循环时间的增加至少部分是由于 GRBL 在规划器缓冲区中没有足够的数据来充分利用其轨迹规划器。所以,我认为解决方案的一部分可能是从简单的呼叫/响应流协议到更高级的字符计数协议。 我的行解析器也做了一些可以帮助的事情。由于它跟踪活动的模态值和坐标数据,因此即使它列在最初读取的代码行中,它也不会随每一行重新发送该数据。它删除了空格和注释,它也切断了坐标中不必要的精度。这是用户在 GUI 用户设置中定义的,但我默认它最多保留 4 个小数位。因此,以 Roadrunner 代码为例。每条线都有一个 G0 或 G1 模态值和坐标到小数点后 6 位。一个典型的代码块如下: G0 X0.000000 Y0.000000 Z0.200000 我的解析器将此块减少到 G0X0Y0Z0.2 这是 248 个字符与 64 个字符(包括 EOL 字符)的差异。我不确定在使用发送/响应协议时会有什么不同,但在字符计数协议中,原始代码将填充接收缓冲区两次,而解析和“清理”的代码只有 1/2 填充接收缓冲区,可能会为 GRBL 提供 4 倍的数据以供其向前看。 也许@chamnit 可以评论他是否认为上述所有因素都会对周期时间产生重大影响。 再次感谢, 约翰·B。 |
我继续实现了字符计数流协议。我这样做是为了在运行时选择字符计数或发送/响应协议。我进行了几次测试,在大多数情况下,没有明显的区别。最大的不同是在我编写的一个测试程序中看到的,它只是将一个轴增加了几千次 0.010 英寸。两者的循环时间为字符计数 25.0 秒,而发送响应为 56.2 秒。显然这不是一个现实的测试,但它突出了字符计数的好处。仅从这个角度来看,使用字符计数协议并没有太多好处。 但是,我发现使用字符计数确实在其他领域受益。我发现的一件事是,简单地启用包含 G 代码文件的数据网格的滚动可以大大增加循环时间。在禁用滚动并运行 roadrunner 文件的情况下,字符计数和发送/响应在每个 2:58 大致相同。使用发送/响应协议时,仅启用滚动会使循环时间增加 37 秒,但使用字符计数时没有变化。在测试字符计数之前,我打算研究减少滚动对循环时间影响的方法,但现在可能不必这样做。当添加程序必须执行的所有内容以跟踪固定周期和未来的 CDC> 时,这也可能会增加周期时间 |
我想我会更新我的 GUI 和固定循环的实现。完全实施被证明是一项相当复杂的任务,至少对于我虚弱的头脑来说。为了完全实现,GUI 必须知道需要跟踪馈送到 GRBL 的每一行的几件事。 例如,G81 钻孔循环需要知道退刀方式(G98/G99),并且需要知道 G81 循环开始时的 Z 高度。由于 GRBL 缓冲命令,因此不可能简单地查询 GRBL 以了解前一个命令的编程 Z 高度是多少。如果在 G90 绝对模式下,人们会认为可以查看上一行来查看编程的 Z 高度是多少,但并不是那么简单。假设程序只是运行了一堆 X,Y 只移动。这可能意味着之前的 Z 指令在 G81 之前 1、2 或 200 步。也有可能之前的命令也是固定循环,在这种情况下,Z 命令是孔的底部,而不是固定循环的终点。因此,这需要为程序的每一行跟踪机器的 Z 位置。 如果说整个程序(包括固定循环)都在 G91 中,事情就更加复杂了。在这种情况下,您必须从发出最后一个 G90 Z 指令的时间开始跟踪,或者从机器在运行开始时空闲的时间开始跟踪。 如果程序切换工作坐标系 (G54-G59),事情会更加复杂。 我有几次开始和重写,但我终于在程序运行期间让它全部工作了。我通过对所有模态值进行默认设置,并在用户点击运行按钮时检查机器位置和偏移量来做到这一点。由于它是如此复杂,我还决定进行单线前瞻,以便将来我可以尝试实施刀具直径补偿 (CDC)。现在我正在跟踪 41 个不同的值,并且正在跟踪它们的 1-previous move、2-current move 和 3-next move。上一步是因为固定循环需要知道其中一些值,例如 G98/G99、之前的 Z 结束位置等。下一步纯粹是为了 CDC。我基本上正在跟踪 LinuxCNC 将拥有的所有内容,即使 GRBL 或我的 GUI 不支持,所以将来我不会 我现在遇到的问题是它在完全实现 G81、G82、G83、G85、G86、G88、G89 的程序运行期间完美运行,但我必须弄清楚如何在 MDI 输入期间使其工作。MDI 期间的固定循环是我最初想要的。我认为我的方法是不允许 MDI,除非 GRBL 空闲并且我可以从 GRBL 状态响应中抢夺机器位置。另一个需要注意的是,除非 G99 专门在 MDI 输入线上,否则我将默认为 G98 缩回模式。本质上是在 MDI 期间使 G98/G99 非模态。我的另一个选择是从第一次与 grbl 的连接开始跟踪这 41 个参数,或者任何时候它看到包含“Grbl”的响应,这表示硬重置或软重置。 仍在努力,但没有足够的时间来做我想要的。我的妻子似乎认为我应该在空闲时间做其他事情!!!! |
必须跟踪状态是 gcode 规范中更不幸的事情之一。要在中途启动程序,您必须运行它并跟踪在此之前发生的所有事情,以确保正确设置所有模式。太可怕了。如果它有帮助,我一直在考虑花一些时间来编写一个完全兼容的 gcode 解析器,GUI 可以拾取和使用它。问题是找到时间和动力来完成它。(将包含宏 B,因此 GUI 可以自动执行自定义机器任务) |
grbl/grbl-sim#3 的一些变化会有帮助吗?它基本上可以让您在 PC 上编译 grbl gcode 解析器,并为您提供相同的输出。我可以想象把它变成交流图书馆。从那里可以很容易地为大多数现代语言提供语言绑定。 |
使用正则表达式和选择案例的解析器实际上并不算太糟糕。不知道最好的方法是什么,但我是这样做的 1- 删除空格 我只能用 2 个正则表达式命令来做到这一点。不知道有多少代码行,但一点也不长。 我遇到的最大问题是试图只追踪我需要的东西,结果却忘记了一些东西。这当然需要一些重写。然后越来越多。然后我最终决定只跟踪所有我需要与否的东西。再加上从来没有成为一个非常优秀的程序员,而且自从我做任何编程以来已经有好几年了,这让我放慢了速度。 我还有一些想做的事情,一旦完成,我想把它交到一些用户手中。我猜你可能会认为他们是 alpha 测试人员,但我计划到那时已经准备好进行测试了。 不过可能还要一两个星期,因为我还有一些其他的事情要处理。 祝我好运 |
我终于有时间在我的 GUI 上做更多的工作,但遇到了一个令人费解的情况。在测试一些东西时,我发现 G2 和 G3 命令无法正常工作。他们不是沿弧线移动,而是简单地从起始位置直线移动到最终位置。这是一个 GRBL 上传,已经运行了大约一个月左右,在此期间没有进行任何更改。我发现这不是由于我的 GUI,而是 GRBL 发生了一些事情。我使用一个简单的串行监视器验证它以发送 G2/G3 命令,但机器仍然直线移动而不是弧线移动。GRBL 上传设置为回显命令,并且确认来自 GRBL 的回显响应正确。我尝试重置和拔掉插头无济于事。我终于使用 Arduino IDE 重新加载了 GRBL 并重置了修复它的 EEPROM 设置。我应该先尝试重置 EEPROM,但没有。但是,我在 EEPROM 设置中看不到任何可以解释这种行为的内容。有没有人遇到过这样的事情? |
@109JB: 你还记得你遇到 G2/3 问题时的版本日期吗?在此期间是否能够看到 EEPROM 设置或存储值有任何问题?是某种类型的弧计算会导致这种情况吗? 我不记得像这样的任何特定问题,除了可能在一年前,我为罕见的弧度情况修复了弧度计算。 |
是的,我应该检查版本日期,但没有,但是当我重新加载 GRBL 时,我没有下载最新的,而是使用了我之前加载的那个。所以我应该能在我回家的时候给你版本日期。我可以告诉你,它是在 6 月底左右从 github 下载的。 当问题发生时,我执行了正常的 $$、$#、$G 和 $N 请求,并没有看到任何异常。我的 $N 块如下: $N1= G90G20G54G17G0G94 当它最初发生时,虽然我可能已经发出了一个命令来解决问题,所以我按此顺序发送了以下命令: G90G20G54G17G0G94 这根本没有产生任何动静,所以我发送了以下内容: G2X2Y0I1J0(起始位置仍为 0,0,0) 这导致线性移动到 x=2 而没有 y 或 z 移动 然后我移回 0,0,0 并发出以下 G2X1Y1I1J0 这导致以 45 度角线性移动到 X=1,Y=1 我还使用 G3 尝试了类似的命令,并获得了类似的仅线性结果。 此时我重新启动了我的 gui,再次尝试了相同的结果。然后我使用一个基本的串行监视器发送具有相同结果的命令。然后重新设置了 GRBL,结果相同。此时我决定重新加载 GRBL 并重置 EEPROM。正如我所说,我应该先完成 EEPROM 重置,看看 EEPROM 是否是问题所在,但我匆忙中忘记了进行故障排除步骤。 |
@chamnit版本日期为 20150620 |
@kfoltman我目前正在研究(又一个)新的发送者,它使用多个线程和一个异步事件循环正是出于这个原因。是的,事实证明它非常复杂!它是用 C/GTK+ 编写的,以提高 RPi 等低端系统的效率,当它准备好使用时,我将把它作为开源发布。 |
@kfoltman我的 gui 确实有能力将轴归零。您只需单击 DRO 的文本,它会弹出一个框来选择您要设置的内容。0.000 是默认值,但您可以输入任何内容。例如,如果使用寻边器,您可以输入 0.100。 |
@kfoltman虽然我没有明确使用线程,但在系统下面,它本质上使用线程。GUI在主线程上,串行响应在它们自己的线程上,我认为一旦发送调用,发送就在它自己的线程上。我阻止的唯一地方是第一次读取文件本身,这只会在读取大文件时产生影响,例如激光雕刻。 如果不对运行时进行分析,就很难确定阻塞在哪里。这很少是直观的(根据大量 Z80 和 68000 代码的经验)。 |
@gerritv是的,这发生在由小段组成的详细轮廓中,因此缺少数据队列协议可能是原因。不幸的是,一些 CAM 程序不能发出圆角的圆弧命令,这使得这种行为更加痛苦。 另一个有趣的事情是,显示的坐标往往落后于机器的实际运动,甚至几秒钟。也许原因是它在暂停之前没有读取整个缓冲区?我尝试更改空闲时间,但找不到合适的设置。 |
只是我现在的 GUI 所在位置的更新。由于工作和家庭的原因,我没有太多时间来研究它,但最近有一些时间。在项目的初始阶段,我看到了隧道尽头的曙光。初始阶段的很多东西是为下一个阶段设置它。 主窗口功能说明: 最上面的 2 行菜单很容易解释: 第二行有常用的 GRBL 命令按钮,以及 5 个用户可定义按钮(宏) DRO 面板具有工作和机器坐标。要将轴归零,请单击轴编号,然后会出现一个窗口,您可以在其中为当前位置设置所需的坐标。例如,如果使用寻边器,您可能希望输入 -0.100″ 而不是输入 0。默认值为 0.000。 点动按钮面板具有用于每个轴的按钮以及用于选择增量或连续点动的按钮。现在只有增量工作。一旦 GRBL V1.0 通过连续点动释放,这将得到修复。下拉框具有慢跑的分级值,但您可以在该框中输入您想要的任何慢跑增量。 左下方的控件用于主轴和冷却液。很不言自明。 主窗口的右侧是一个选项卡式框。一个选项卡用于 MDI 输入和串行端口监控。上部 MDI 输入面板的工作方式与 LinuxCNC 中的 MDI 非常相似。单行框是您键入的当前 MDI 输入框,上面的框显示 MDI 历史记录。您可以使用向上/dn 箭头或单击历史记录框以将先前的行放入当前的 MDI 输入框。 下方的串行监视器显示 GRBL 发回的内容。有一个复选框,您可以关闭状态报告的连续流。 G-Code File 选项卡是放置要运行的 G-code 文件的位置。有2个盒子。上面是 G 代码文件,下面显示选择“运行”后的运行进度。G 代码可以在文本框内进行编辑。 所有的盒子都可以调整大小 最后,状态条具有当前 GRBL 状态、文件发送进度条、计划缓冲区状态、接收缓冲区状态、循环计时器和时钟。 现在工作的内容: 上述固定循环在 G90 和 G91 中都完全实现,并记住模态值,因此例如,以下 2 行代码将产生 2 个钻孔,一个在 x=2,y=4,深度为z=-1″,另一个在 x=5,y=7。 G90G98G81X2Y4Z-1R0.1 工具更换正在使用工具表进行。 您输入描述,并保存工具表。在程序运行期间,M6T# 命令将从表中拉出刀具长度。它与 NIST/LinuxCNC 实践有点不同。例如,这个程序只需要一个 M6T# 命令来更改刀具和设置偏移量,而 NIST/LinuxCNC 需要一个 M6T# 来更改刀具,然后是一个 G43H# 命令来设置偏移量。我还做了它,以便您可以存储多个工作的工具表(现在 10 个) M1 可选停止支持正在工作。 让这一切发挥作用是一条漫长的道路。固定循环需要跟踪模态值、跟踪编程位置等,因为 GUI 正在处理的行可能比 GRBL 正在处理的行落后很多行,而且机器在计算期间可能处于运动状态这一事实意味着我必须在 GUI 中跟踪所有这些,而不是能够查询 GRBL。此外,固定循环的 GRBL 等效运动证明要正确编程有些乏味。想想 G91G83 啄钻循环。每个孔可以有数百个线性移动,如果有一个 L 重复值,您可以很容易地进入发送到 GRBL 的数千条命令,用于一条固定循环线。但它的工作!!!! 未来的计划,如果我能解决的话: 我有几个小错误要解决,然后我想把它交给几个人来做一些 beta 测试。没有时间表,因为在我可以攻击那些剩余的小错误之前,需要完成一些家庭/工作的事情。 干杯, 约翰·B。 |
哇,很棒的工作! 你有机会分享代码吗?如果是这样,我真的很喜欢副本!rasciodc@gmail.com 谢谢!! PS:我正在研究 4 轴热线切割机,目前没有很好的软件来处理 4 个独立的轴,显然你的! |
实际上,由于 grbl 还不支持 4 轴,所以我的 GUI 也不支持。当 grbl 确实支持 4 个轴时,A 轴标签只是作为一个占位符。 此外,我的 GUI 的这个特殊版本已经过时了。我一直在做一个新的,但它还没有完成。 |
我懂了。实际上,有一些努力使 GRBL 的 4 轴版本非常实用。如果你在 github 上寻找 Letartare 和 Skwee,你会找到他们的作品。特别是,Skwee 的版本在我的机器上工作(我已经将它调整为在 RAMPS 板上使用,并且已经用它切割了一些翅膀,使用主轴命令和 HeatBed 输出来控制镍铬合金线)。
实际上,我在寻找读取 GCode 并将其发送到 arduino 的方法时遇到了您的 GUI。我现在正在使用 VB 开发自己的 4 轴刀具软件,当时我决定没有现成的软件可以满足我的需要。2天前我开始深入研究… 我要求您编码的原因是验证有效读取 txt 文件的方法,将行加载到表中(显示在 GUI 中),以某种方式存储代码行(使用数组或缓冲区)并将其发送到一个一个到arduino,确保没有遗漏任何命令。我一直在阅读一些论坛,看到您通过消除状态栏等提高了程序的速度……所以我认为这对我来说可能是一个很好的起点…… 不过,这只是一个起点,因为我现在使用的是 Dan Royer(“Marginally Clever”,也在 GitHub 中)提供的一个更加简化的控制器,考虑到热线非常简单,它似乎工作得非常好机器并且不需要铣削CNC所做的所有调整。 |
干得好 |
您需要生成 G 代码才能控制任何 CNC 控制器。运动涉及更多,例如移动的速度或首先移动的方向。查看 LinuxCNC Doc 关于 G-Code。2017-04-25 4:39 GMT-03:00 rcsaz <notifications@github.com>:
|
我不确定你在问什么,但无论如何我都没有时间帮助任何编码。 如果您只想输入坐标并让机器移动,那么如前所述,您需要阅读 g 代码。非常简单,Grbl 可以从任何串行终端程序获取命令,并且只需键入它们即可移动到坐标,但是您必须通过准备命令告诉它您希望它如何完成 G0 表示尽可能快地移动 所以, G90 G1 F10 将设置 Grbl 以 10 个单位/分钟的绝对坐标移动 |
哇,伟大的工作! 你有机会分享VB代码吗?如果是这样,我真的很喜欢副本!jinfu77@gmail.com 谢谢!! |
好工作。我看完了你的视频。但我看到你的 vb 只生成 gcode。不要将您的 gcode 发送到端口或机器。我真的很想知道 vb 如何将 gcode 发送到端口。不要使用 grbl 来操作机器。 |
109JB 评论 on 21 Apr 2015
我在业余时间一直在研究我的 GUI,并认为我会对其进行更新。它几乎包含了我想要实现的所有主要组件。这没什么特别的,但我需要一台可以在我想在商店中使用的老式笔记本电脑上运行 Windows 98 的笔记本电脑。我不是程序员,但可以做一个好的黑客工作。现在 GUI 就在那里,并具有我想要的以下功能。
以上所有内容都已完成,以下是一些未来的增强功能
至于效果如何。它做得很好。我在以下链接的 Youtube 上有一段视频。不是最漂亮的,但做得很好。我一直在测试它,从 10 行程序到 10,000 行程序。视频显示我的工厂使用我的 gui 在 grbl 上运行,以每分钟 120 英寸的速度执行 roadrunner 程序。linuxCNC 也有相同的运行,以相同的编程进给率运行相同的程序。结果非常有趣。
程序:Roadrunner CNC G 代码程序
程序行:4,471 行长
程序进给率 120 IPM
快速进给率 GRBL 上 150IPM,LinuxCNC 上 180 IPM
我的 GUI/GRBL 的循环时间 – 3 分钟,20 秒
LinuxCNC 的循环时间 – 5 分钟35 秒
在运行过程中,我注意到与 GRBL 相比,LinuxCNC 在编程移动之间的减速要明显得多。我的 LinuxCNC 版本已经有几年历史了,我知道 LinuxCNC 有一个新的轨迹规划器,因此差异差距可能会缩小,但 GRBL 能够做到的仍然令人印象深刻。我已经对丢失的步骤进行了广泛的检查,并且没有像我现在拥有的那样丢失设置步骤。
顺便说一句,我还将我的 GUI 运行与 GRBL 面板和通用 G 代码发送器进行了比较。在这两种情况下,我都比它们中的任何一个慢了大约 5%,但我还没有构建我的项目,并且仍在调试模式下运行。希望构建后它会快一点。
我通过我的标准并行端口分线板使用 Arduino NANO 与机器连接。这是那个界面
这是 GUI 视频的链接以及 GRBL 和 LinuxCNC 头对头运行。
http://youtu.be/c1mxS7WI-tg