人们制作了通过 telnet 进行通信的吊坠。在代码库中有一些用于在 oled 显示器上显示内容的代码，通过 Config.cpp 中的#defines 启用。我有一个长期计划来制作一个由旋转编码器控制的菜单系统，但它正在让位于包括错误修复在内的大量其他任务。有一个使用 Grbl_Esp32 并包含触摸屏的 Makerbase 产品，但他们还没有发布源代码，所以我们不知道他们到底做了什么。

这绝对是我们中的一些人感兴趣的事情，但现在我们不想因为思考它而分心，因为我们的眼球正忙于更紧迫的任务。

我是来找这个的。
我们需要较低层的挂件支持，而不是通过 uart（或其他传输 gcode 的通道）。

只是一个想法：它可以通过主 mcu 上的 USB Host HID 和一个简单的游戏手柄来完成。
游戏手柄上的模拟操纵杆可以移动具有可变进给的轴。

我很想准确地慢跑我的机器

Esp32没有USB接口。这些模块通常有一个 USB 转串口芯片，连接到 ESP32 上的 UART 串​​口线

我认为澄清您所看到的问题可能会有用。

听起来像一个抱怨排队太多的点动操作？

或者问题是对点动请求的响应延迟？

但这有点令人困惑，因为你最后提到了准确性。

可能短期内解决不了，但是把问题表达清楚，对以后的参考很有用。:)

我认为澄清您所看到的问题可能会有用。

听起来像一个抱怨排队太多的点动操作？

或者问题是对点动请求的响应延迟？

但这有点令人困惑，因为你最后提到了准确性。

可能短期内解决不了，但是把问题表达清楚，对以后的参考很有用。:)

我认为它可能是两者的结合，尤其是 telnet。Web 界面反应不够灵敏，很容易不小心点击太多次或点击错误的地方，这就是为什么挂件会好得多。

UART pendant 可能工作正常，但尝试编写 arduino 代码以将 pendant 输入转换为 g 代码并连接到 ESP32 对我来说是一项艰巨的任务。所以在我尝试之前，我真的不能说这是否能解决问题。

所以按下按钮后开始运动需要很长时间？
我没有注意到这是一个问题，它似乎反应灵敏。

还是它能让你在运动中排队慢跑？

还是当慢跑变得过多时很难取消慢跑？

对我来说，这个问题可能只是网络延迟和使用 PC 或平板电脑与网页交互的固有潜在错误的结合。

我可以排队 5 个慢跑动作，它可能需要 10 或 15 秒才能开始执行第一个动作。直接连接到电路板的硬件输入会更快，而且即时反馈很有帮助。

在实际观察运动中的机器时，手持控制器的触觉反馈也值得一提。这就是大多数真实商店中的机器操作员如何让机器四处转动，我认为这是一种更直观和“准确”的方式，而不是在计算机屏幕和机器之间来回查看并试图猜测您点击了多少次需要。

慢跑 – 尤其是用户按下按钮开始和松开停止的实时类型 – 由于输入获取、gcode 解析、运动规划和运动执行的各个步骤和队列中的延迟，比您想象的要复杂得多。

也就是说，这里有一个想法，可以用一种快速而肮脏的方式来破解某种吊坠。这个想法是你使用一些普通的渠道，如串行或 telnet 或 web 来设置参数 – 轴。方向和缩放 – 然后有一个直接连接到 GPIO 引脚的“开始”按钮。当该按钮被按下时，通过用于宏按钮的相同方法将 $J= jog start 命令插入队列，当它被释放时，执行与 JogCancel 实时角色相同的操作，即设置 rtMotionCancel 标志.

Esp32没有USB接口。这些模块通常有一个 USB 转串口芯片，连接到 ESP32 上的 UART 串​​口线

我可以看到 ESP32-S2 有 USB On-The-Go。

我认为澄清您所看到的问题可能会有用。

听起来像一个抱怨排队太多的点动操作？

或者问题是对点动请求的响应延迟？

但这有点令人困惑，因为你最后提到了准确性。

可能短期内解决不了，但是把问题表达清楚，对以后的参考很有用。:)

一个有用的点动控制器应该提供以下功能（说到经验）：

• 按下移动按钮：机器开始向所需方向移动
• 按下按钮时：机器继续移动
• 松开按钮的瞬间：机器尽快停止运动

我们的经验是，如果我们“连续”按下点动按钮，命令会叠加，因此我们无法确定机器何时/何地停止。

就我个人而言，我坚信这只能通过在扩展板上提供一个额外的接头来解决，用于连接点动控制器或手摇手摇控制器。所有命令（点动控制器接口）都应在核心级别处理，例如，如果机器未执行 g 代码，则可以激活点动控制器，如果机器正在执行 g 代码，则点动控制器将被停用。更新的位置是通过 UART 轮询的，因此 UI 端没有问题。

这是 PlanetCNC 控制器实现点动控制器的方式，它运行得非常好：

https://planet-cnc.com/using-jogging-keyboard-with-planetcnc-controllers/

我想着手解决这个问题并尝试实现它，但我只是在 ESP32 世界中跳跃，这意味着这需要一些时间。

这给出了更清晰的画面:)

我们在这里谈论的是人类的响应时间，这非常慢。
我想象如果机器空闲，那么即使通过网络接口也应该有良好的响应时间。
我认为使用 Mitch 上面提到的实时点动取消听起来可行。

我一直在玩弄网络 io——我会看看能否在几天内整理出一个概念证明，让它可以通过网络浏览器进行控制。

慢跑 – 尤其是用户按下按钮开始和松开停止的实时类型 – 由于输入获取、gcode 解析、运动规划和运动执行的各个步骤和队列中的延迟，比您想象的要复杂得多。

也就是说，这里有一个想法，可以用一种快速而肮脏的方式来破解某种吊坠。这个想法是你使用一些普通的渠道，如串行或 telnet 或 web 来设置参数 – 轴。方向和缩放 – 然后有一个直接连接到 GPIO 引脚的“开始”按钮。当该按钮被按下时，通过用于宏按钮的相同方法将 $J= jog start 命令插入队列，当它被释放时，执行与 JogCancel 实时角色相同的操作，即设置 rtMotionCancel 标志.

在我看来，朝着正确的方向前进。

我想有人在谈话的早些时候提到过，我也有同样的想法，是不是可以通过在硬件级别控制慢跑来最大程度地减少延迟？如果我们有一个编码器的 GPIO 输入，或者甚至只有一个带有方向和步数控制的点动按钮，那么较低级别的信号不是比转换为 gcode、通过 UART 发送、然后再次解码更灵敏吗？

1. 防止太多点动命令排队的关键是让每个命令只移动很短的距离。
2. USB 是一大堆蠕虫
3. 支持 S2 本身就是一项艰巨的任务。也许有人可以让演示快速运行，但演示和可支持的产品之间存在天壤之别。
4. 人类看到事件和按下按钮的响应时间大约为 300 毫秒 – 计算机时间的永恒。但见上文（1）。如果由单个点动步骤事件启动的运动比事件的自动重复率长，则会发生超限。关键是要么使单个运动时间与重复率相对应，要么使用点动取消。

解决这个问题需要在各个方面对系统进行分析。到目前为止，我在上面的评论中看到的是猜测和一厢情愿的想法，认为一些闪亮的新事物会神奇地解决问题。

1. The key to preventing too many jog commands from queuing up is to make each command move only a short distance.

2. USB is a huge can of worms

3. Support for the S2 in and of itself is a substantial task.  Maybe somebody could get a demo working quickly, but there is a world of difference between a demo and a supportable product.

4. Human response time to seeing an event and pressing a button is on the order of 300 milliseconds - an eternity of computer time. But see (1) above.  If the motions that are initiated by individual jogging step events are longer than the auto-repetition rate of the events, overrun will occur.  The key is to either make the individual motion times correspond to the repetition rate, or else use jog cancel.

解决这个问题需要在各个方面对系统进行分析。到目前为止，我在上面的评论中看到的是猜测和一厢情愿的想法，认为一些闪亮的新事物会神奇地解决问题。

听起来实现比我想象的要复杂。我出差到不同的机械车间工作，并且习惯于看到几乎每个 CNC 都配备了转轮。我想我假设有一个简单的方法来控制机器的运动。

我想我更愿意追求使用微型 USB 端口上的 UART 连接而不是任何基于 telnet 的东西，因为我在 ESP3D 中遇到的延迟。根据您提到的 300 毫秒响应时间，我猜测某种去抖动可以解决排队太多命令的问题。对我来说最困难的部分是编写将硬件输入转换为 G 代码的代码，但有一段时间，我想我可以让它工作。

商业级 CNC 机器不是使用最初为 Arduino 玩具计算机编写的软件和硬件制造的。在商业级机器上，一切都在同一台计算机上运行。在 GRBL 世界中，机器控制是在一个微型处理器上完成的，具有有限的、几乎不存在的用户显示能力。我们正在尝试使用 FluidNC 解决这个问题，但用户控制表面硬件和运动控制硬件之间的根本脱节仍然存在，grbl 运动引擎的深层架构也是如此。

问题根本不是去抖动。请仔细阅读我所说的内容。问题在第 1 项和第 4 项中进行了说明 – 点动命令设备的重复率与点动增量之间的脱节。使用 WebUI 和 WiFi 的不可预测的延迟，很难接近不可能调整它们以匹配。应该可以通过直接连接的东西来做到这一点——但问题不是弹跳，而是调整速率。

我们可以停止猜测吗？