我不确定我是否理解🤔

您正在寻找的功能是使异步command + reply变为同步的功能吗？

例如，今天如果你想发送一个命令并找出该命令的结果，你需要实现并注册一个ControllerListener。

但是使用建议的UGSserial.writeConsoleCommand(“command”)它会阻止操作，等待并返回来自控制器的响应？

啊 – 我明白我做了什么，那主要是我在写建议时的糟糕尝试，同时我过于关注可能性。
因此，微处理器上的操作肯定不会被阻塞，并且该进程必须具有侦听器功能。你也是正确的，因为函数 UGSserial.writeConsoleCommand(“command”) 对于串行消息传递是完全错误的。（我有时会陷入程序思考）
它可能更像是：（只是想强调无阻塞）
loop（）{
if（cmdtriggered）sendUGScmd（cmd）
if（responseavailable）readUGSresponse（）
}
sendUGScmd（cmd） {
Serial.write(packet, headers, len, etc…)
resetsendtriggers()
}

该功能归结为能够仅使用 UGS 的命令行界面对自定义微控制器挂件进行编程。这个想法源于 UNO 引脚已用尽，我不想将我的 Uno 更改为 Mega，而且我仍然想保留和使用 USG UI，因为它显示了所有可用的东西。

根据我的阅读，人们已经设法让 DIY 吊坠使用键盘仿真来工作，但似乎也有一个问题，那就是它都是单向通信，并且只有应用程序具有正确的焦点。我想如果有一个微处理器可以直接与命令行接口而不依赖于应用程序焦点，并且能够解析信息/机器状态的响应，我可以从吊坠中获得更多。（我知道我必须编写大量的响应解析逻辑。但我只有一组有限的按钮/开关我想添加，所以我知道这是一项可行的任务。
例如，切换 MPG 刻度 (0.1,1,10,100)，切换 MPG 选择（X,Y,Z,Feed,Speed,Jog），切换偏移量（M,1,2,3,4,5） 大量按钮（主页Machine, Zero All, Zero X/Y/Z/F/S, Goto XYZ Zero, Goto XYZero, Dust, Light, Feed Hold, Start/Resume, Reset/Abort, ProbeZ, ProbeAll, Unlock/SoftReset, 几个宏按钮). 所有常见的东西，哦，我会添加一个小的 OLED 来查看偏移和机器的 XYZ 位置，使用软按钮和 LCD 名称显示来显示宏按钮，因为，你知道的……花哨的:)

好的，所以你想使用串行通信与 UGS 集成，好主意。我现在没有时间处理这样的功能（也许其他人感兴趣？），所以与此同时我可以给你一些其他选择。

选项 1 – 使用“中间人”硬件，它将代理与控制器（即 GRBL）的所有通信，并发送自己的命令。即使它应该是可能的，也不是一个好主意。因为 UGS 试图跟踪所有发送的命令和收到的响应。如果它得到一堆“OK”响应，它不知道任何事情，UGS 内部就会变得混乱，并且可能会出现错误。

选项 2 – 使用现有的 REST/RPC API。它的文档有点缺乏，但如果您阅读代码，应该很容易理解。如果您激活 UGS 中的“Pendant”，它将开始收听网络电话。
这个解决方案的唯一缺点是它需要轮询状态并且协议会变得非常冗长。对此的解决方案是 WebSockets，但我们还没有。

选项 3 – 使用游戏手柄或操纵杆。这只允许单向通信，但可以与选项 2 结合使用。此选项的最大优点是它允许使用模拟控制。

感谢您的想法。
对于选项 1，我已经按照您的建议将 XLcd ( https://wiki.shapeoko.com/index.php/XLCD ) 之类的东西作为硬件代理进行调查。但正如您还提到的，我宁愿不生成返回 UGS 的未知响应。我确实看到有人通过接入 RX/TX 线路在线路上添加了一个与二极管的单向连接。但是，我还是不想生成未知的响应。任何与用户手动将命令键入 UGS 控制台实际上相同的东西都是目标。这样，UGS 就会知道正在发送的请求。

对于选项 2，这是否类似于该项目的实施方式？( https://discuss.inventables.com/t/prototype-ugs-pendant/47171/3 ) 感谢 REST/RPC 的链接。我今天会读那些。

对于选项 3，我可能会退回到游戏手柄的键盘模拟器。个人喜好比什么都重要，但我知道其他人更喜欢那种控制类型。