Enhancing CNC Workflow: Integrating ESP-NOW Distributed Functionality and RESTful API Scripting with FluidNC Controllers

[thebacons]

I'm currently exploring methods to integrate my CNC workflow with decentralized and remote functionality for controlling external devices. These devices include standalone stepper motors (e.g., for tool changers, lowering and raising dust guards, laser, etc.) and 240v switches. However, my current FluidNC controller lacks built-in options for controlling more than four stepper motors and for managing external devices such as a vacuum or air-assist powered by 240v /24v .

I'm curious to know if others have already explored similar solutions or if there are workarounds available within the FluidNC controller or CNC client software.

Reviewing Options:

1. ESP-NOW Distributed Network:

   • ESP-Now could potentially address some of the limitations of my CNC controller, especially regarding the limited number of stepper motor ports.
   • By integrating ESP-Now into a CNC controller running FluidNC, we can enhance flexibility, scalability, and reliability while simplifying the integration process and reducing interference-related issues.
     • Increased Connectivity: Each stepper motor driver equipped with an ESP-Now enabled microcontroller can directly connect to the CNC controller via ESP-Now, surpassing the physical port limitations.
     • Simplified Wiring: ESP-Now's Wi-Fi communication eliminates complex wiring schemes, simplifying setup and reducing the chance of wiring errors.
     • Scalability: Adding more devices becomes easier without the constraints of physical wires, avoiding significant rewiring or hardware modifications.
     • Wireless Connectivity: Enables wireless communication between the CNC controller and other devices, eliminating cumbersome wiring and allowing flexible deployment.
     • Reduced Interference: Minimizes electromagnetic interference within the CNC controller cabinet, ensuring signal stability.
     • Ease of Integration: Natively supported by the ESP32 microcontroller, ESP-Now simplifies the development process for wireless communication capabilities in ESP32-based CNC controllers.

2. Triggering RESTful API Endpoints:

   • I aim to trigger RESTful API endpoints, such as controlling a Shelly device (Shelly PM1), adjusting settings, retrieving data, or performing other supported actions.
   • Integrating scripting functionalities for external control via REST API offers several benefits:
     • Utilize Existing Hardware: My vacuum and air assist are already connected to a Shelly 1PM, eliminating the need for additional relays and power supplies, simplifying the setup.
     • Reduced Complexity: Avoids complexity and cost increases associated with integrating switching control functionalities directly into CNC controllers.
     • Minimized Noise: External devices like Shelly relays can help minimize EMF noise introduced by built-in switching circuits within the CNC controller.
   • Assigning a new G-Code to trigger enhanced macros, such as turning on the laser and air-assistance via a Shelly, could look like:

     M3
     MS <http://Shelly-IP-Address/relay/0?turn=on>
     

These solutions offer innovative ways to enhance CNC workflows, providing greater control, flexibility, and efficiency. Does anyone have any thoughts or additional ideas on these approaches?

[MitchBradley]

Two words: support nightmare.

[MitchBradley]

Let me explain that in more detail.

1. ESP-NOW adds a network protocol that none of the developers currently have any familiarity with, either at the controller level or the peripheral level. Networking protocols are inherently complicated, often require substantial amount of RAM (something we are already low on), and can be very difficult to debug, requiring deep dives through multiple levels of a complex stack at both ends.
2. Our user base in general has little experience with it, so anybody who tries to use it is likely to ask endless n00b questions that nobody can answer, often based on hardware that nobody else has and thus the situation cannot be duplicated.
3. Wireless networking is inherently unsuited for synchronized operation of stepper motors, so it would only work for an auxiliary stepper that is used for some low-speed, high-latency purpose.

FluidNC is already at the point where it enables more different hardware configurations than can be effectively supported from a human standpoint. If you look at the questions we get on Discord, it seems like every day somebody wants to do something entirely different using barely-documented hardware from China, while at the same time wanting extensive basic handholding for things that are relatively simple. Few of them contribute, and of the sporadic contributions that we do get, most will barely pay for breakfast. So the developers are working for the equivalent of about $0.10 per hour. Adding greatly to the support burden is the last thing we want to do.