开源改变世界!!

DIY 吊坠串行连接 #1447

推推 grbl 1年前 (2023-01-28) 158次浏览
关闭
wile1411 打开了这个问题 2020 年 10 月 12 日 · 6条评论
关闭

DIY 吊坠串行连接#1447

wile1411 打开了这个问题 2020 年 10 月 12 日 · 6条评论

注释

DIY 吊坠串行连接 #1447
wile1411 评论了 2020 年 10 月 12 日  

功能要求

只是一个插件的想法,它建议人们在需要时扩展其机器功能的方法。

建议使用一个插件,让您可以为微处理器选择一个 COM 端口,以与 G 代码 API 函数交互。我建议的初始用例是使用建议的串行连接来制作“花哨的”CNC 吊坠。它将避免键盘仿真器挂件解决方案带来的所有问题。(鼠标焦点、动作延迟、快捷方式规划等…)

相反,串行连接可以连接到 Arduino,后者将直接通过 API 发出命令。来自插件端的代码需要能够将发送的 Gcode 命令传递给机器并返回带有返回消息的回复。

来自微处理器串行连接的示例命令:
response = UGSserial.writeConsoleCommand(“$H”)
MachineStateParser(UGSserial.writeConsoleCommand(“$G”))
PositionParser(UGSserial.writeConsoleCommand(“?”))

通过这种方式,人们可以制作和编码他们自己的吊坠版本,并添加他们想要的任何按钮、滚轮和状态更改。当然,它类似于内置 UGS 吊坠的可用功能,但这将允许人们提出他们自己的(理想情况下可共享的)解决方案,并希望减轻您的一些开发负担,以提出一个通用的解决方案解决方案。

DIY 吊坠串行连接 #1447
合作者
布雷勒 评论了 2020 年 10 月 12 日  

我不确定我是否理解🤔

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

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

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

DIY 吊坠串行连接 #1447
作者
wile1411 评论了 2020 年 10 月 12 日  

啊 – 我明白我做了什么,那主要是我在写建议时的糟糕尝试,同时我过于关注可能性。
因此,微处理器上的操作肯定不会被阻塞,并且该进程必须具有侦听器功能。你也是正确的,因为函数 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 名称显示来显示宏按钮,因为,你知道的……花哨的:)

DIY 吊坠串行连接 #1447
合作者

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

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

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

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

DIY 吊坠串行连接 #1447
作者

感谢您的想法。
对于选项 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,我可能会退回到游戏手柄的键盘模拟器。个人喜好比什么都重要,但我知道其他人更喜欢那种控制类型。

DIY 吊坠串行连接 #1447
所有者
绕线机 评论了 2020 年 10 月 13 日 通过电子邮件
DIY 吊坠串行连接 #1447
所有者
绕线机 评论了 2020 年 10 月 13 日 通过电子邮件