注释
.png "提要覆盖问题 #1052"){kind=avatar}
|
我不知道 Sonny 有什么计划，但我之前用 在 2016 年 8 月 10 日下午 12:39，“109JB” notifications@github.com写道： Sonny， 我终于有一些空闲时间来处理我的 gui，并且在这样做的过程中，我一直在 所以，如果你还没有为此准备好的方法，我可以建议一个 如果这已经计划实施，那么请关闭此问题。 — |
.png "提要覆盖问题 #1052"){kind=avatar}
|
@109JB: Grbl v1.0 的 feed（和 rapid）覆盖实时执行，并使用扩展 ASCII 空间中的一组新的实时命令字符进行命令。大约有 15-16 个新命令。确保您的 GUI 可以像其他 GUI 一样发送扩展的 ASCII ~, !, ? 命令。在选定的 v1.0 测试人员中，一些人在使其在某些编程环境中工作时遇到了一些问题。我认为这与默认字符编码问题有关。 这些命令具有 +/- 粗略和精细调整，默认分别为 10% 和 1%。还有一个 100% 重置命令。Grbl 会将编程的进给速率乘以进给倍率比例因子，并在 50-60 毫秒内执行。因此无需使用此新功能更改 g 代码程序本身中的 F 字。 获得即时反馈非常棒，这样您就可以调入最佳切割速度而不会冒过度的风险。只需聆听机器的声音，就可以很容易地以 +/- 1% 的速度接近它。人们一直在用 F 字更改来破解覆盖的方式存在问题。您必须等待缓冲区清除太长时间，并且有损坏/磨损刀具或过度使用机器的风险。 无论如何，将按要求关闭此问题。 |
.png "提要覆盖问题 #1052"){kind=avatar}
|
编辑 g 代码文件充其量也很麻烦。如果一个程序被反复使用，那么它肯定是需要做的事情，以便下次运行时进给率是正确的。我不使用UGS，但我知道现在的GRBL做不到这一点。我一直在编写自己的 GUI，主要是为了适应我自己的使用，并且如前所述，我做了一个测试。我可以在 g 代码运行时更改进给率，方法是注入一个新的进给率，该新的进给率是现有进给率的倍数，但这不会像它应该的那样立即生效。 问题是用户需要能够在机器运行时实时更改进给率。在这一点上，在我看来，这是目前 grbl 最大的垮台。当机器运行时，用户出于各种原因需要能够减慢或加速机器。例如一个未经测试的新程序在运行中用户发现进给速度太快或太慢。也可能是现有程序的情况，其中刀具可能有点钝。另一种情况可能是为具有或多或少切削刃的刀具编写的程序。例如，为 4 刃立铣刀编写的程序中的进给率对于 2 刃立铣刀需要减半。这些只是例子， |
|
桑尼，你在我打字的时候回复了。很高兴听到它预定用于 V1.0。迫不及待地想看到它。 |
|
我同意你的观点 109，尽管我认为在 feed over ride 之前应该添加一些其他问题，例如限位开关测试、反冲补偿和步进校准插件（我假设其中 2 个实际上取决于 GUI） 也许我只是习惯于使用业余爱好/开源的东西，其中需要一些手动工作来完成工作并且不再这样做。与等待进给覆盖相比，我更容易找出我的机器切割得好的地方，并始终使用这些进给 + 速度，尽管在接下来的几个月里这将是一个非常好的奢侈。 |
|
@jahnj0584: 如果我有空间（机会很小），我打算添加反冲补偿。无论哪种方式，它都会在 v1.0 发布后很快安装在 Mega 版本上。 |
|
伟大的。反正我要买一个新的arduino，我应该做什么型号，那不是Uno吗？我正在寻找 32 位或更高版本以获得更好的加速和脉冲 |
|
@jahnj0584：将 Grbl 直接移植到 32 位平台只会给你更高的脉冲率。整体运动不会有太大变化。我目前正在开发一种新的 32 位控制器，它将充分利用计算能力，但我不会详细说明。 |
.jpg "提要覆盖问题 #1052"){kind=avatar}
|
我知道您和我们一样都很忙，但我对 v1.0 发布的大致时间框架感到好奇。 谢谢！ |
|
@tklus: 看我的回答。[https://github.com/ /issues/1046 #issuecomment-237035359] |
|
：） 谢谢！ |
|
桑尼，你能再解释一下提要覆盖的工作原理吗？听起来好像会有 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 保存的命令而是在运行时注入的？只是好奇。 |
|
@109JB：它以 Haas 控制器为模型，因此可以通过按下按钮而不是滑块来更改覆盖值。非常适合实时命令字符结构。当然，我可以添加一些内容以允许通过 $ 字符串设置特定值，但它不是实时的。该命令可能必须在串行 RX 缓冲区中等待，或者如果 Grbl 在接受新命令之前等待完成排队的命令。 即使我可以让“$”命令实时执行，我会说我已经考虑过它并且已经收到过对同样事情的请求。但是，我认为为 v1.0 开发它不会增加闪存成本或额外的发布延迟。个别命令应该没问题。无论如何，您真的不想将值设置得太低或太快。在实践中，有争议的是最好不要通过设置一个值来过度补偿。 也就是说，一旦 v1.0 beta 发布。作为社区讨论，将有一些空间可以对它如何与 GUI 一起工作进行小的调整。但是，我不打算在 v1.0 之后开发 Grbl 的 328p 版本，因为我们已经遇到了困难。它只会处于维护模式。所以记住这一点。大多数这些更好/下一代的想法都被引入了高级 ARM 版本，其中的通信协议将有很大不同，并且更适合于适应诸如实时设置覆盖值之类的事情。 |
|
明白了。没问题，主要是好奇心。如前所述，无论如何，它都可以通过几行代码在 gui 代码中实现。 我进入预发布版本测试人员名单的机会有多大？ |
Sonny，
我相信您正在为 grbl 的 V1.0 版本进行提要覆盖，所以如果是这种情况，那么这是一个没有实际意义的问题，可以忽略不计。
我终于有一些空闲时间来处理我的 gui，并且在这样做的过程中，我一直在考虑 GUI 级别的 feed override。我混搭了一个测试，它可以完成，但我的方式是，如果在 gui 中更改了 feed override 滑块，它会在发送的下一个命令中添加一个 F 字。G 代码中的任何后续 F 字都具有滑块值，范围从 0.01 到 2.00（1 到 200 %），用作乘数。问题是这只适用于下一个要发送的命令，并且在接收到添加/修改的 F 字之前，grbl 队列中已经存在的任何命令都必须运行。
所以，如果你还没有为此准备好的方法，我可以建议一个新的 $ 命令，也许是 $F，它是一个提要覆盖，可以立即读取并作为标量应用于 G- 中的普通 F 命令代码。我不知道 grbl 代码的来龙去脉，因为我不太了解 C 编程，所以也许这是一种行不通的幼稚方法，但这是一个想法。
如果这已经计划实施，那么请关闭此问题。