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