开源改变世界!!

提要覆盖问题 #1052

推推 grbl 2年前 (2022-10-31) 251次浏览 0个评论
关闭
109JB 开了这个issue on 10 Aug 2016 · 14 条评论
关闭

提要覆盖问题#1052

109JB 开了这个issue on 10 Aug 2016 · 14 条评论

注释

提要覆盖问题 #1052

Sonny,
我相信您正在为 grbl 的 V1.0 版本开发提要覆盖,所以如果是这种情况,那么这是一个有争议的问题,可以忽略。

我终于有一些空闲时间来处理我的 gui 并且这样做我一直在考虑在 GUI 级别覆盖提要。我做了一个测试,它可以完成,但我的方法是,如果在 gui 中更改了提要覆盖滑块,它会在发送的下一个命令中添加一个 F 字。G 代码中的任何后续 F 字都有滑块值,该值的范围为 0.01 到 2.00(1 到 200 %),用作乘数。问题是这只适用于要发送的下一个命令,并且任何已经在 grbl 队列中的命令都必须在收到添加/修改的 F 字之前运行。

因此,如果您还没有为此准备的方法,我可以建议一个新的 $ 命令吗,也许 $F 是一个提要覆盖,可以立即读取并作为标量应用于 G- 中的正常 F 命令代码。我不知道 grbl 代码的来龙去脉,因为我不太了解 C 编程,所以也许这是一种行不通的幼稚方法,但这是一个想法。

如果这已经计划实施,那么请关闭此问题。

提要覆盖问题 #1052

我不知道 Sonny 有什么计划,但我之前使用
notepad++ 编辑了我的提要并使用了替换选项 [搜索 F(value),替换为
F(value)],然后您可以保存一个运行得更快或更慢的副本. 有
没有办法 grbl 或 UGS 可以自动执行此操作?

2016 年 8 月 10 日下午 12:39,“109JB”notices@github.com写道

Sonny,
我相信您正在为
grbl 的 V1.0 版本开发提要覆盖,所以如果是这种情况,那么这是一个有争议的问题,可以
忽略。

我终于有一些空闲时间来处理我的 gui 并且这样做我一直在
考虑在 GUI 级别覆盖提要。我做了一个测试,它
可以完成,但我的方法是,
如果在 gui 中更改了提要覆盖滑块,它会在发送的下一个命令中添加一个 F 字。G 代码中的任何后续 F
字都有滑块值,该值的范围为 0.01 到 2.00
(1 到 200 %),用作乘数。问题是这只适用
于要发送的下一个命令,并且任何已经在 grbl 队列中的命令都必须
在收到添加/修改的 F 字之前运行。

因此,如果您还没有为此准备的方法,我可以建议一个
新的 $ 命令吗,也许 $F 是一个提要覆盖,可以立即读取
并作为标量应用于 G- 中的正常 F 命令代码。我不
知道 grbl 代码的来龙去脉,因为我不太了解 C 编程
,所以也许这是一种行不通的幼稚方法,但这是
一个想法。

如果这已经计划实施,那么请关闭此问题。


您收到此消息是因为您订阅了此线程。
直接回复此邮件,在 GitHub
#1052上查看,或将帖子静音
https://github.com/notifications/unsubscribe-auth/AQlzDKQuR_bp0dbnu2n3dyUE8qlLhHxrks5qefBMgaJpZM4JhRzX

提要覆盖问题 #1052

@109JB:Grbl v1.0 的提要(和快速)覆盖实时执行,并使用扩展 ASCII 空间中的一组新的实时命令字符进行命令。大约有 15-16 个新命令。确保您的 GUI 可以像其他 ~, !, ? 命令。在选定的 v1.0 测试人员中,有些人在使其在某些编程环境中工作时遇到了一些问题。我认为这与默认字符编码问题有关。

这些命令具有 +/- 粗调和微调,默认分别为 10% 和 1%。还有一个 100% 重置命令。Grbl 将编程进给率乘以进给倍率比例因子,并在 50-60 毫秒内执行。因此,无需使用此新功能更改 g 代码程序本身中的 F 字。

获得即时反馈非常棒,这样您就可以调出最佳切割速度,而不会冒过度的风险。只需听机器,就可以很容易地用 +/- 1% 偷偷摸摸。人们一直在用 F 字更改进行覆盖的方式存在问题。您必须等待缓冲区清理太久,并且有损坏/磨损刀具或过度使用机器的风险。

无论如何,将按要求关闭此问题。

提要覆盖问题 #1052
作者

109JB 评论 2016 年 8 月 11 日

编辑 g 代码文件充其量是繁琐的。如果一个程序被反复使用,这肯定是需要做的事情,以便下次运行时进给率是正确的。我不使用 UGS,但我知道当前的 GRBL 无法做到这一点。我一直在编写自己的 GUI,主要是为了适应我自己的使用情况,并且如前所述,我做了一个测试。我可以在 g 代码运行时更改进给率,方法是注入一个新的进给率,它是现有进给率的乘数,但这不会立即生效。

问题是用户需要能够在机器运行时更​​改进给率并实时执行此操作。在这一点上,我认为这是 grbl 在这个时间点上最大的失败。当机器运行时,出于各种原因,用户需要能够减慢或加速机器。例如,一个未经测试的新程序在运行中用户发现进给速度太快或太慢。这也可能是现有程序中刀具可能有点沉闷的情况。另一种情况可能是为具有或多或少切削刃的刀具编写的程序。例如,为 4 刃立铣刀编写的程序中的进给率需要为 2 刃立铣刀减半。这些只是例子,

提要覆盖问题 #1052
作者

109JB 评论 2016 年 8 月 11 日

桑尼,你在我打字的时候回复了。很高兴听到它计划用于 V1.0。迫不及待地想看到它。

提要覆盖问题 #1052

我同意你的观点 109,尽管我认为在超载之前应该添加一些其他问题,例如限位开关测试、间隙补偿和步进校准插件(我假设其中 2 个实际上取决于 GUI)

也许我只是习惯于使用业余爱好/开源的东西,需要一些手动工作来完成工作,然后就这样了。与等待进给覆盖相比,我更容易找出我的机器切割得好的地方,并始终使用这些进给 + 速度,尽管在接下来的几个月中拥有这将是一种非常好的奢侈。

提要覆盖问题 #1052

@jahnj0584:如果我有房间(机会很小),我打算添加反冲补偿。无论哪种方式,它都会在 v1.0 发布后很快安装在 Mega 版本上。

提要覆盖问题 #1052

伟大的。反正我要买一个新的arduino,我应该用什么型号,那不是Uno吗?我正在寻找 32 位或更高版本以获得更好的加速度和脉冲

提要覆盖问题 #1052

@jahnj0584:将 Grbl 直接移植到 32 位平台只会为您提供更高的脉冲率。整体运动不会有太大变化。我目前正在开发一个新的 32 位控制器,它将充分利用计算能力,但我不会详细说明。

提要覆盖问题 #1052

我知道你和我们一样都很忙,但我很好奇 v1.0 版本的大致时间表。

谢谢!
蒂姆

提要覆盖问题 #1052

:) 谢谢!

提要覆盖问题 #1052
作者

109JB 评论 2016 年 8 月 11 日

桑尼,你能解释一下提要覆盖是如何工作的吗?听起来好像会有 5 个实时命令 +1%、-1%、+10%、-10% 和恢复 100%。

我试图思考如何将它实现到我的 GUI 中。来自 LinuxCNC,它使用滑块和快捷键来实现提要覆盖,我试图设想如何实现同样的方法。例如,在 linuxCNC 中,如果您想从 100% 到 10% 进给覆盖,您只需按“1”键即可达到 10%。2 键 = 20%、3=30% 等。

假设进给率最初是 100%,而用户想要达到 10%。听起来新的 grbl 实现必须达到 100% – 90% – 80% …10%。这个对吗?不是什么大问题,gui 只需要进行一些计算并发送多个命令。

如果上述内容正确,是否有任何理由无法简单地使用带有变量的单个实时命令实现覆盖,例如 $F=0.1 用于 10% 进给率?这不是 eeprom 保存的命令,而是在运行时注入的?只是好奇。

提要覆盖问题 #1052

@109JB:它以 Haas 控制器为模型,因此可以通过按钮而不是滑块来更改覆盖值。它非常适合实时命令字符结构。当然,我可以添加一些内容以允许通过 $ 字符串设置特定值,但它不会是实时的。该命令可能必须在串行 RX 缓冲区中等待,或者如果 Grbl 在接受新命令之前等待完成排队的命令。

即使我可以实时执行“$”命令,我会说我已经考虑过了,并且收到了过去对同样事情的请求。但是,我认为为 v1.0 开发闪存成本或额外的发布延迟不会增加太多价值。各个命令应该没问题。无论如何,您真的不想将值设置得太低太快。在实践中,有争议的是最好不要通过设置一个值来过度补偿。

也就是说,一旦 v1.0 测试版发布。作为社区讨论,将有一些空间对其如何与 GUI 一起使用进行小幅调整。但是,我不打算在 v1.0 之后开发 328p 版本的 Grbl,因为我们已经重创了闪存墙。它将仅处于维护模式。所以记住这一点。大多数这些更好/下一代的想法都被引入了高级 ARM 版本,其中的通信协议将有很大不同,并且更适合于实时设置覆盖值等内容。

提要覆盖问题 #1052
作者

109JB 评论 2016 年 8 月 11 日

明白了。没问题,主要是好奇心。如前所述,它可以在 gui 代码中实现滑块,只需几行。

我进入预发布版本的测试人员名单的机会有多大?

提要覆盖问题 #1052
喜欢 (0)

您必须 登录 才能发表评论!