宏目前非常有限（没有变量、计算等…）。只有纯 G 代码…我也梦想硬件按钮提供更多功能。例如：Probe Z、Probe XYZ、Probe with Z tool length offset 等……不幸的是现在不可能。我可能会尝试一下……你知道为什么你的拉取请求被关闭了吗？我也有一个分支，其代码与您的代码几乎相同，但后来我意识到已经有一个具有相同功能的封闭 PR …

宏的数量：多少就足够了？选择一个数字，下一个人会想要更多，如此无穷无尽的问题。编号宏的当前体系结构不能很好地扩展。WebUI 有一个更好的设施，其中宏存储在文件中。

变量和计算：这是一堆涉及添加表达式解析器的蠕虫病毒。语言的范围是什么，它在哪里停止？将类似的东西添加到用更动态的语言（如 JavaScript）编写的 UI 代码中会更容易。

是的，我真的明白宏中的“变量和计算”将是一项非常大的努力，超出了 FluidNC 的范围……但我仍然认为可以通过控制引脚开发和激活一些更高级别的功能。我们一直使用的非常有用的功能是有限的，我真的很讨厌为了这些东西回到 UI。如果您查看人们在 CNCjs ( https://github.com/cncjs/CNCjs-Macros ) 中开发的宏（带有变量和计算），绝大多数都与探测和工具更改有关（在特定位置探测并应用新位的 Z 偏移量）。能够使用 +/- 按钮覆盖进给率和主轴 RPM 也被证明是有用的。

我的最终目标是仅依靠 UI 来准备和启动工作，然后使用物理按钮进行剩余（最终）操作：在工作期间调整进给和速度、暂停/恢复、转到工具更改位置、探测一个新位，应用偏移量并继续下一个操作。就是这样……我曾经使用由 makerfr 开发的一个小型 GRBL 控制器，它集成了所有这些东西（https://github.com/mstrens/grbl_controller_esp32），但它仍然基于具有多个级别的触摸屏菜单）。

至于宏的数量。我知道人们总是想要更多……但是 4 并不多。这是我一直使用的宏示例：Homing、Goto WCS X0 Z0。转到 WCS Z0，设置探测位置，转到探测位置，解锁 ($X)。那里是6…

对不起，冗长的帖子！

解决宏数量问题的一种方法是将它们存储在文件中。原则上按钮可以被分配来访问文件驻留宏而不是存储在配置中的宏。这就引出了一个问题，即有多少按钮可分配给此类宏。现在很少有足够的 GPIO 留给很多按钮宏。根据 Stefan 正在进行的输入扩展器工作，这可能很快就会改变，但目前拥有大量按钮宏通常是不切实际的。

已经可以使用 WebUI 来增加宏的数量。但这并不能解决变量问题。

我很清楚 CNCjs 的工作原理，因为我是极少数的 CNCjs 开发人员之一，也是唯一一个在 Facebook CNCjs 用户组上提供大量支持的人。CNCjs 宏语言相当广泛。让您使用相当大的 JavaScript 表达式语法子集。实现它的代码相当复杂。大多数用途可能确实不太全面 – 但一旦你开始将某些东西变成一种编程语言，你就会遇到这样一个问题，即总会有人只想要一个小功能。如果您从具有简单语法的简单子集开始，那么在某些时候您会遇到语法砖墙，因此您真的应该考虑一般问题并在一开始就采用完整的语法。这意味着一个高风险的设计问题。

WebUI 已经有进给率和主轴覆盖

这也与某些功能有关，例如在剪辑轮廓上移动，这些功能要么需要专门实现，要么在具有一定编程能力的宏中完成。我知道每个人都有不同的需求，但是通过可编程宏，您可以让用户自己填补空白，而不必重新发明轮子。

例如，在另一个项目中完成此操作的一种方式是 Klipper，它允许在配置中设置任意数量的宏，然后它们就变成新的“Gcode”，您可以从终端或任何其他工具调用它将 gcode 发送到机器。这对我来说似乎是一个非常好的方法，因为我不限制用户在使用 jinja2 解析时做复杂事情的能力，这在某种程度上是当前配置文件https://www.klipper3d的 yaml 格式的标准.org/Command_Templates.html

也许从 Klipper 项目（已经处理 gcode）中借用一些东西可能会在所需的时间和精力上产生更大的投资回报率

我们的跟踪系统中存在这些问题。

目前，我们的大部分时间都花在了新用户支持上，因此我们主要致力于解决问题和功能以帮助他们。我们的时间有限，但有很多高级功能请求。