您使用什么用户界面发送命令？发件人？串行终端？通过 USB 串口或蓝牙？请提供有关命令路径中所有内容的完整详细信息，以便我们可以复制您的设置。

这可能与您的问题无关，但我看到您的 A 轴有 max_travel_mm: 0。0 不是 max_travel_mm 的有效值。

Bart 和我整个上午都在尝试重现这个问题，使用带有计步模块的 DSLogic 逻辑分析仪来计算步数。我们谁都不能让它失败。我们尝试了 v3.6.4，它是当前主版本的构建版本，也是我最新的开发代码。我们尝试了 WiFi 和蓝牙版本，使用 FluidTerm 访问 BT 串口桥。

在这一点上，为了取得进一步的进展，我们需要有关您的设置的大量信息，以便我们可以发现您的环境与我们尝试过的环境之间的差异。您的硬件照片、有关软件（发送器、串行终端或其他 UI 代理）的完整信息、您发送命令所通过的设备和连接、显示它连接到系统位置的 PLC 设置照片等。

此外，请注意，在“G0 X500 F13000”中，“F13000”部分对 G0 指令没有意义。G0 以最大轴速运行，不使用 F 值。F只对G1、G2、G3有意义。当您将“Fn”添加到 G0 命令时，它会影响下一个 G1、G2 或 G3，但不会影响同一行上的 G0 移动。那不是导致您的问题的原因，但我认为您应该知道。

您可能在想“但它适用于 3.4.4，所以它不可能是我的硬件”。答案是“是的，但即使您的硬件没问题，您的设置也可能与 3.4.4 和 3.6.4 之间的细微差别相互作用”。

你好@MitchBradley

我今天不在我的工作室，所以我画了一个示例原理图来展示我如何将 esp32 与 plc 连接，并且“G0”是我发送的实际打字错误（G1 X500 F13000），

我正在使用 A 轴作为旋转轴，我希望 A 轴无限大，这就是为什么我使用 0 作为最大行程的原因，如果我能做任何其他事情，请指导我。

我尝试的发件人 – UGS、OpenBuildsCONTROL 和适用于 Android 的 grbl 控制器应用程序，我同时尝试 USB 和蓝牙

关于 A 轴：最好的办法是不指定 max_travel_mm（不要在配置文件中包含该行）并为该轴设置 soft_limits: false。FluidNC 仅在两个地方使用 max_travel_mm

1. 如果轴具有 soft_limits: true，则使用 max_travel_mm 的值以及 mpos_mm 和 positive_direction 来计算轴限制值。如果轴的 soft_limits 为 false，则限制检查代码不使用 max_travel_mm
2. 如果为轴启用了归位，则 max_travel_mm 用于确定初始归位方法在放弃之前将走多远，以防找不到限位开关。如果未在轴上启用或执行归位，则 max_travel_mm 不用于该目的。

某些 UI 可能会使用 max_travel_mm 来确定机器限制，以显示机器边界。大多数 UI 都有单独的方法来配置机器边界，而无需询问控制器固件。

非常感谢您的指导。

如果缺少步骤问题需要任何其他信息，请告诉我，我将在此处共享所有信息。

我将 6n137 光耦合器用于高低信号，因为它是非常快的光耦合器，而 plc 只能处理 24v 脉冲，这就是为什么需要光耦合器。

关于丢失步骤的原始问题：我没有想法。我们尝试以多种方式重现该问题，但从未发现可归因于丢失步骤的失败。

我确实看到过这样一种情况，在重置后的第一个动作中，机器的移动量低于预期。我将其追踪到工作坐标偏移量。G54 坐标系有一个固定的 X 偏移量：-10。如果不执行归位步骤，则重置后 mpos 的初始值为 0。WCO = -10，因此工作位置的初始值为 10，因此“G1 X500 Fn”移动从 10 变为 500 ，因此距离为 490。随后的移动，比如“G1 X0”，移动了完整的 500 毫米。

每次 plc 读取不同的脉冲，所以我认为这不是 10mm 的问题，因为当我切换回 3.4.4 时，一切正常，所有读数都是正确的。

我明天订购了新的 esp 32 我会在它到达我的商店时进行更新，我会用新的 ESP 测试所有东西。

你好，

为耦合器提供 24 V 电压是否正确？我发现 6N137 类型的所有数据表（例如：https : //datasheet.lcsc.com/lcsc/1811131221_CT-Micro-International-CT6N137_C191866.pdf）具有 7V 电源的绝对最大额定值。即使您为耦合器提供 5V 电压，集电极开路输出的绝对最大额定电压也为 7V。因此，这种类型的耦合器不可能实现高达 24 V 的电平转换。还是我找错了组件？

你好@ModuloFS

我正在使用它只是为了测试这里是我的 PCB 原理图。出于测试目的，24v 将适用于 Fluid NC v3.4.4

我们真的需要我要求的所有背景。只有一个元素的示意图并不能揭示可能有什么不同。

请尝试通过 USB 使用 FluidTerm。这是我们最容易复制的环境。

到目前为止，您的所有测试都使用了在 Android 上运行的发送器，这样说是否正确？

也许在 3.4.4 版本中你会得到一个略有不同的脉冲宽度时序，因此它可以正常工作。如果您将这种类型的光耦合器用作 24 伏的电平转换器，您可能会得到奇怪的输出信号形状。由于这种不良的输出信号形状，您的计数逻辑计数错误？

你好@MitchBradley

我只分享一个元件，因为我只使用一个即用型光耦合器模块对其进行测试。让我分享我的设置照片 我正在测试东西，因为我正在为流体 NC 开发完全定制的 PCB，这就是我单独测试东西的原因。

我不明白这@ModuloFS “也许在 3.4.4 版本中，您的脉冲宽度时序略有不同”您能解释一下 v3.4.4 和 v3.6.4 之间的主要区别是什么吗

3.4.4 和更高版本之间的主要区别在于使用了最新的 Espressif 库。那破坏了很多东西。在此问题之前，我们已经成功地重现了弹出的用户问题。

一个问题是 UART 通信在 3.4.4 之后干扰了 RMT。它导致丢失步骤。芯片的另一个功能可能仍然会导致问题。在我们能够重现它之前，很难知道。

在 3.4.4 之后，我们切换到更新版本的 ESP-IDF SDK 以及位于其之上的相应新版本的 Arduino Framework。该转换的目标有三个。一个是避免卡在将不受支持的旧版本上——事实上，第一个触发因素是当有人抱怨说当 PlatformIO 自动更新到新的 Arduino 框架时我们的构建脚本不起作用。其次，我们想从 flaky 的 SPIFFS FLASH 文件系统迁移到更新更好的 LittleFS 文件系统；旧的 SDK 不支持 LittleFS。第三，我们希望支持一些较新的 ESP32 变体，如 ESP32-S2，为此需要新的 SDK。

转换过程一点也不顺利。新的 Arduino 框架中存在错误，驱动程序的默认行为发生变化，编译器版本变化导致原子访问原语等内容过时，核心驱动程序中的 API 变化，WiFi 身份验证变化等等。版本 3.4.5 – 3.5.x 充满了难以诊断的问题。从 3.6.1 开始，情况开始好转，但我们仍然发现 API 差异会导致微妙的问题。

与此同时，我们收到了来自以下人员的支持请求：想要全新功能的人、有硬件设计缺陷的人声称固件有问题、从根本上误解了 GCode 的工作原理的人、询问有关违反 GPL 许可条款的中国仿制品问题的人、不完整的人我们不得不乞求并乞求获得评估问题所需信息的问题，以及更多的干扰。这些人中有一小部分会捐赠给该项目，因此我们大部分时间都是免费进行所有这些开发和支持工作的。

自 3.4.4 以来已经有 275 次提交，所以“主要区别”很难识别。即使我确实选择了一些特别的东西，那是正确猜测的机会也几乎为零。

请回答有关 Android 的问题和 FluidTerm 的建议。我们需要一个可以重现的特定设置。

嗨@MitchBradley

我正在使用 Android 应用程序和与 fluid nc 的蓝牙通信。

我不擅长编码，你能告诉我你是如何计算脉冲的吗？我可以用 Arduino 来做吗，就像程序 1 Arduino 用于计算脉冲，如果可能的话，用串口监视器读取它，你能帮我写 Arduino 代码吗？所以我避开了 plc 和光耦合器模块，直接用 Arduino 计算 3.3v 脉冲。

我正在使用带有步进电机解码模块的 dslogic 逻辑分析仪。我明天会为 ESP32 写一个脉冲计数草图。这里很晚了

你好@MitchBradley

感谢您的帮助，每当您编写代码时，请在此处发布代码。我将使用第二个 esp 32 来计算脉冲并在此处更新。

https://github.com/MitchBradley/PulseCounter是 ESP32 的脉冲计数器

嗨@MitchBradley

感谢您的努力，我明天会品尝它并在这里更新我正在等待我的新 esp 32 我很确定它明天会 delever。

我发现 3.6.4 和 3.4.4 之间存在差异 – 3.6.4 更快。3.6.4，以100K步/秒的巡航速度步进时，有的脉冲正好相隔10us，有的长一点，有的短一点，保持100K/秒的平均速度。最长的间隔是 12 us，最短的是 8。

对于 3.4.4，当名义上以 100K/秒的速度巡航时，平均速度接近 80K/秒，脉冲之间的间隔从 12 us 到 14 us。

在这两种情况下，逻辑分析仪都显示发出了所有 200K 脉冲。在 3.4.4 中，一个g0 x 500动作需要 3.5 秒，而在 3.6.4 中同样的动作需要 2.84 秒。

两种情况下的配置文件都相同，4us 脉冲，400 步/mm，15000 mm/min 最大速率（= 250 mm/sec），300 mm/sec2 加速度。2.9 秒的时间是正确的——0.833 秒以 300 毫米/秒的速度加速到 250 毫米/秒，再加上 0.83 秒的减速时间。加速期间的行进距离为 104 毫米，因此加速 + 减速为 208 毫米。剩下 292 毫米的巡航速度，用时 1.17 秒。所以总共 2.84 秒

在进给率 13000 ( g1 x500 f13000) 时，3.6.4 仍然比 3.4.4 快，500 毫米需要 3.1 秒。

对于 3.6.4，您已将 F 值降低到 12000，以使其在巡航速度下表现得像 3.4.4。

我的猜测是您的外部硬件——无论是外部驱动程序还是 PLC——几乎无法跟上 100K/秒的步进速度，尤其是当 100K 是平均速率时，一些脉冲靠得更近一些，有些则分开得更远。

不幸的是，在最初的报告中，您告诉我们的关于您的外部硬件的唯一内容只是“diy”和“plc”。这些信息不足以确定此类硬件可能有多快。

你好@MitchBradley

我明天测试了 2 台设备，第一个是“esp32”，第二个是高速伺服驱动器，

使用 esp32 – G01 x500 f15000，脉冲 – 200000
G01 x0 f15000，脉冲 – 199998

带伺服驱动器 – G01 X500 F15000，脉冲 – 200000
G01 x0 f15000，脉冲 – 200000

我发现 F14000 正在制造一些混乱，它会丢失 1 或 2 个步骤，否则一切正常。

最后，我发现这是我的 plc 故障，也许 plc 输入无法处理那么快的脉冲率，感谢您的时间和他 lp，也感谢您提供脉冲计数器代码。