我没有“现成的 gcode 发送器”，但我通过 WiFi 通过 TCP（telnet）连接从我自己的程序发送 G 代码命令（通过 UI 调整一些参数，单击“执行”然后关闭它发送） G 代码通过 TCP 连接到 FluidNC。

与旧电话调制解调器类似，我必须对我的控制器进行一次初始化（例如发送 $H 并等待它不会出错）。但这对我来说没关系。

那么你有什么问题？

关于“我不认为我的系统细节很重要”：当某些东西不起作用时——但对其他人有用——细节总是很重要的。

“现成的 gcode 发送器”说起来容易，但很难确定。有很多 GCode 发送器，但只有极少数被积极维护。过去，几乎所有的 GRBL 控制器都在只有串行连接的 AVR 上运行，并且是从相同的源代码编译而来的，唯一实质性的变化是版本，通常是 0.9 或 1.1。

通过 WiFi 或以太网连接的能力最近才出现，并且以不同的形式出现，具体取决于 GRBL 的分支或变体 – grblHAL、Smoothieware、Grbl_Esp32/FluidNC，可能还有其他。没有关于它应该如何工作的协调规范，因为这些变体的开发人员专注于他们自己的利益并且没有在任何重要级别上合作（我曾经联系过 grblHAL 开发人员并提议与 UGS 一起进行一些协调；他是’感兴趣）。由于没有关于网络连接如何工作的通用规范，而且大多数 GRBL 无论如何也不支持它，因此发送方开发人员没有很大的动力在上面花费大量时间。事实上，许多甚至大部分现有的“现成”发送器都没有任何活跃的开发人员。

因此，在网络连接方面，“现成的 gcode 发送器”几乎不是问题。有一些特定的发送器支持网络操作并与特定的 GRBL（或 Smoothieware）变体一起工作，但作为一个广泛的类别，大多数 gcode 发送器不支持网络连接。一个具体的例子是 IOSender，它针对 grblHAL 进行了大量调整——事实上，它主要是为了测试和展示 grblHAL。在 FluidNC 领域，我们支持 ESP3D WebUI 并确保其正常工作。据报道，UGS 可以工作，但我们无法控制它的开发，只能不时与它的开发人员交谈——但他通常很忙。

关于通过网络连接到 FluidNC 的推荐方法：您可以在 $Telnet/Port 参数给定的端口上使用原始 TCP 连接，也可以在 $HTTP/Port + 1 上使用 WebSocket 连接——通常是端口 81。我更喜欢 websockets . 在任何一种情况下，您都可以通过结果流发送标准 GRBL 线路协议，使用与串行线路相同的“ok/error”流量控制。（记录不详 – 它是由第三方开发的）HTTP API 可用于将文件上传和下载到 SD 和本地 FLASH 文件系统。您也可以使用它来发送单独的命令（也可以通过 TCP/websocket 流发送），但是 HTTP API 不适合像发送者那样流式传输 GCode。

综上所述，从本地 SD 卡运行 GCode 比通过网络流式传输（“发送”）更好。如果网络出现问题，SD 卡不会中断工作。如果有一个有线以太网连接，那可能是流式传输 GCode 的一个很好的通道——实际上它可能比 USB 串行更好，USB 串行对来自主轴和电机的电噪声非常敏感——但 ESP32 针对 WiFi 进行了优化，很少有有线以太网.

我们将几乎所有有限的开发和支持时间都花在了使用 WebUI 的 WiFi 操作，从 SD 卡运行 GCode 的用例上。我们可以控制该连接的两端，并且可以确保它正常工作。有些人喜欢通过 USB 串口使用传统发送器，我们对此提供了很好的支持。少数使用支持某种形式的网络连接的极少数发件人之一，但到目前为止，这只是用户的一小部分，并且由于我们不控制这些发件人的发展，因此我们无能为力以确保它们完美无缺地工作。还有一些挂件使用 TCP 进行慢跑和工作启动。