Description
After opening the webUI, it closes automatically after 2-3 seconds showing a websocket connection error. The problem was reported and closed with a comment that it couldnot be duplicated in #996 . But here this issue is duplicated in my case without any possible fix after multiple failed attempts.. When using ESP3D (versions 3.0.0 and 3.0.1) on a NodeMCU (ESP8266) to bridge to an Arduino Mega 2560 running Grbl-Mega-5X, commands sent via the Web UI HTTP endpoint (/command?cmd=) return a generic "ESP3D says: command forwarded" message. However, the actual serial output from the target board (such as GRBL status or settings) is not returned in the HTTP response. Additionally, WebSocket connections required for real-time DRO updates consistently fail across both versions.
Expected Behavior
Sending a command like ? or $$ via the HTTP API should return the actual serial data from the Arduino Mega (e.g., <Idle|MPos:0,0,0...> or $0=10...) directly in the response body. The WebSocket connection should be stable to allow the WebUI to update coordinates in real-time.
Actual Behavior
HTTP API: Sending http://[IP]/command?cmd=? results in the string ESP3D says: command forwarded, but no GRBL status data is received by the browser.
WebSocket Failure: Connection attempts to ws://[IP]/ws or ws://[IP]:81 consistently result in a WebSocket connection failed error in the browser console. This issue is identical in both v3.0.0 and v3.0.1.
DRO Stagnation: Because the API does not return coordinates and the WebSocket fails, the WebUI remains "Disconnected" or fails to update position, even though the serial bridge is physically active via other ports (Telnet).
Code Observations (Command/Accept Handling)
The issue appears linked to how ESP3D v3 handles command synchronization compared to v2.x. Specifically:
In the current code, the command processing logic (related to the _accept or process function for incoming requests) immediately triggers a "forwarded" acknowledgement to the web client.
The logic within the available() check for the serial buffer appears to be bypassed or decoupled during the HTTP request lifecycle. While the command is successfully sent to the board, the return data is not being pulled from the serial stream back into the same HTTP session or WebSocket stream.
This asynchronous behavior in the _accept mechanism seems to prevent the firmware from waiting for the serial response before closing the HTTP output, effectively breaking the feedback loop for real-time GRBL monitoring.
This represents a significant change from the synchronous response pattern in v2.x.
Steps to Reproduce
Flash ESP3D v3.0.0 or v3.0.1 to a NodeMCU (ESP8266).
Connect to an Arduino Mega 2560 running Grbl-Mega-5X at 115200 Baud.
Access the official ESP3D WebUI (v3.0.0-alpha3).
Send any command via the terminal.
Observe the "forwarded" response in the logs and the "WebSocket connection failed" error in the browser inspector.
Hardware
ESP Board: NodeMCU v2 (ESP8266)
Flash Size: 4MB
Target Board: Arduino Mega 2560
Firmware on Target: Grbl-Mega-5X (4-axis foam cutter)
Firmware & WebUI Version
ESP3D Firmware: Tested on 3.0.0 and 3.0.1
ESP3D WebUI: 3.0.0-alpha3 (official release)
Communication Settings
Baud Rate: 115200
Mode: Bridge / Telnet Enabled
Additional Context
While the Telnet bridge (Port 23) functions correctly for external G-code senders, the integrated WebUI is non-functional for machine control because it cannot retrieve the serial stream or establish a WebSocket connection. For 4-axis Hotwire CNC applications, the lack of real-time position reporting via the WebUI makes it impossible to monitor tapered cuts or wire positioning safely.
Description
After opening the webUI, it closes automatically after 2-3 seconds showing a websocket connection error. The problem was reported and closed with a comment that it couldnot be duplicated in #996 . But here this issue is duplicated in my case without any possible fix after multiple failed attempts.. When using ESP3D (versions 3.0.0 and 3.0.1) on a NodeMCU (ESP8266) to bridge to an Arduino Mega 2560 running Grbl-Mega-5X, commands sent via the Web UI HTTP endpoint (/command?cmd=) return a generic "ESP3D says: command forwarded" message. However, the actual serial output from the target board (such as GRBL status or settings) is not returned in the HTTP response. Additionally, WebSocket connections required for real-time DRO updates consistently fail across both versions.
Expected Behavior
Sending a command like ? or $$ via the HTTP API should return the actual serial data from the Arduino Mega (e.g., <Idle|MPos:0,0,0...> or $0=10...) directly in the response body. The WebSocket connection should be stable to allow the WebUI to update coordinates in real-time.
Actual Behavior
HTTP API: Sending http://[IP]/command?cmd=? results in the string ESP3D says: command forwarded, but no GRBL status data is received by the browser.
WebSocket Failure: Connection attempts to ws://[IP]/ws or ws://[IP]:81 consistently result in a WebSocket connection failed error in the browser console. This issue is identical in both v3.0.0 and v3.0.1.
DRO Stagnation: Because the API does not return coordinates and the WebSocket fails, the WebUI remains "Disconnected" or fails to update position, even though the serial bridge is physically active via other ports (Telnet).
Code Observations (Command/Accept Handling)
The issue appears linked to how ESP3D v3 handles command synchronization compared to v2.x. Specifically:
In the current code, the command processing logic (related to the _accept or process function for incoming requests) immediately triggers a "forwarded" acknowledgement to the web client.
The logic within the available() check for the serial buffer appears to be bypassed or decoupled during the HTTP request lifecycle. While the command is successfully sent to the board, the return data is not being pulled from the serial stream back into the same HTTP session or WebSocket stream.
This asynchronous behavior in the _accept mechanism seems to prevent the firmware from waiting for the serial response before closing the HTTP output, effectively breaking the feedback loop for real-time GRBL monitoring.
This represents a significant change from the synchronous response pattern in v2.x.
Steps to Reproduce
Flash ESP3D v3.0.0 or v3.0.1 to a NodeMCU (ESP8266).
Connect to an Arduino Mega 2560 running Grbl-Mega-5X at 115200 Baud.
Access the official ESP3D WebUI (v3.0.0-alpha3).
Send any command via the terminal.
Observe the "forwarded" response in the logs and the "WebSocket connection failed" error in the browser inspector.
Hardware
ESP Board: NodeMCU v2 (ESP8266)
Flash Size: 4MB
Target Board: Arduino Mega 2560
Firmware on Target: Grbl-Mega-5X (4-axis foam cutter)
Firmware & WebUI Version
ESP3D Firmware: Tested on 3.0.0 and 3.0.1
ESP3D WebUI: 3.0.0-alpha3 (official release)
Communication Settings
Baud Rate: 115200
Mode: Bridge / Telnet Enabled
Additional Context
While the Telnet bridge (Port 23) functions correctly for external G-code senders, the integrated WebUI is non-functional for machine control because it cannot retrieve the serial stream or establish a WebSocket connection. For 4-axis Hotwire CNC applications, the lack of real-time position reporting via the WebUI makes it impossible to monitor tapered cuts or wire positioning safely.