Title: GRBL (Network) with FluidNC (MKS DLC32 V2.1) connects over WebSocket but homing and jobs do not run

[chamusquino]

Description

I am using Rayforge 1.1.2 on Windows with a Makerbase MKS DLC32 V2.1 board running FluidNC v3.7.6 over WiFi.

The controller works perfectly with LaserGRBL over WiFi (Telnet port 23) and also works fine with Rayforge over USB (GRBL Serial).

With Rayforge using GRBL (Network), the machine connects over WebSocket but:

$H (homing) does not move the machine.

No job can be started; preview/simulation fails with an error in the log.

Hardware / Firmware

Board: Makerbase MKS DLC32 V2.1

Firmware: FluidNC v3.7.6

WebUI: ESP3D-WEBUI @84de794

FluidNC status (WebUI):

Web port: 80

Data port (Telnet): 23

IP: 192.168.1.43

Mode: Client station, WiFi connected and stable

Rayforge setup

Version: 1.1.2

Machine driver: GRBL (Network)

Hostname/IP: 192.168.1.43

WebSocket port: 81

Connection status: Rayforge reports connected; WebSocket also works from browser at http://192.168.1.43/ws.

What works

USB (GRBL Serial) + Rayforge:

Homing $H works.

Jogging and running jobs work as expected.

WiFi + LaserGRBL:

Connects over Telnet port 23.

Homing and jobs run correctly.

What does not work (Rayforge GRBL Network + FluidNC)

Homing:

From Rayforge G-code console, sending $H when connected over WiFi does not move the machine.

No obvious ALARM: or error: message is shown (the machine is not in Alarm, and homing works with the same FluidNC config via USB/LaserGRBL).

Running jobs:

Clicking Preview/Simulation or trying to start a job shows these errors in the Rayforge terminal/log:

text
2026-03-09 19:17:12,457 - rayforge.ui_gtk.mainwindow - ERROR - Failed to aggregate ops for preview/simulation
RuntimeError: Job dependencies are not ready. Please wait and try again.
2026-03-09 19:17:12,497 - rayforge.ui_gtk.mainwindow - ERROR - Failed to aggregate ops for preview/simulation
RuntimeError: Job dependencies are not ready. Please wait and try again.
The same document and operations work correctly when I switch the same machine to USB (GRBL Serial).

Connection logs:

I also saw this error earlier when configuring the WebSocket port:

text
ERROR - Port could not be cast to integer value as '1.0'
This happened when the WebSocket port field was interpreted as 1.0 instead of an integer.
After explicitly setting 81 as integer, the connection is established, but homing and jobs still do not run.

Steps to reproduce

On FluidNC (MKS DLC32 V2.1):

Configure WiFi in client mode and confirm WebUI at http://192.168.1.43.

Confirm WebSocket endpoint at /ws works from browser.

Confirm homing and jobs work via LaserGRBL over Telnet port 23 and via USB with Rayforge.

In Rayforge 1.1.2:

Create or open a document with at least one valid operation (cut contour, etc.) and verify the toolpath preview is generated.

Configure machine as: GRBL (Network), Hostname/IP 192.168.1.43, WebSocket Port 81.

Connect to the machine (connection is successful).

Open the G-code console and send $H.

Observe:

The machine does not move for $H.

Attempting to preview or run the job shows Job dependencies are not ready. Please wait and try again. even though the same project works over USB.

Expected behavior

GRBL (Network) should behave similarly to GRBL (Serial) with FluidNC:

$H should initiate the homing cycle.

Jobs that run fine via USB should also run over WebSocket as long as the connection is established.

Question

Is GRBL (Network) officially expected to work with FluidNC WebSocket (MKS DLC32), and if so, is there any known limitation or extra configuration needed (e.g. specific status report settings, buffer handling, or homing commands) to get homing and job execution working over WiFi?

If useful, I can provide:

Full Rayforge debug logs while sending $H and starting a job over WiFi.

FluidNC config.yaml for the MKS DLC32 V2.1 laser setup.

Thanks a lot for any guidance or for clarifying the current level of FluidNC support in GRBL (Network).

[knipknap]

Thank you for the bug report! Could you attach a debug dump .zip file? It is in Help -> "Save debug log" and contains detailed information about the communication of Rayforge with your device. This should allow to identify the issue.

[chamusquino]

Attached is the requested file. Thank you very much. El lun, 9 mar 2026 a las 21:41, Samuel ***@***.***>) escribió:

…

*knipknap* left a comment (barebaric/rayforge#165) <#165 (comment)> Thank you for the bug report! Could you attach a debug dump .zip file? It is in Help -> "Save debug log" and contains detailed information about the communication of Rayforge with your device. This should allow to identify the issue. — Reply to this email directly, view it on GitHub <#165 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPITKQB2U23UXHLNYAJAPFT4P4T6HAVCNFSM6AAAAACWMGSY3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMRWG43DOOBXHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[knipknap]

Looks like that did not work - I think you have to upload it directly on Github, email attachments don't work.

[chamusquino]

Attached is the requested file.

Thank you very much.

rayforge_debug_2026-03-10_21-32-42.zip

[knipknap]

Thank you, that clears some things up. There is actually a chance that your device can already work: By selecting the Smoothie driver instead a a Grbl driver. That communicates via Telnet, so it may work.

The GrblNetwork driver cannot work because it relies on HTTP working, which FluidNC does not support.

[chamusquino]

Additional info: On FluidNC (WebUI / telnet), both $H and $h start homing and respond with ok. In Rayforge (Smoothie / Telnet driver), typing $H or $h in the G‑code console does not start homing and I get: Connection status: ERROR - Command '$h' not confirmed If I start homing directly from FluidNC (WebUI) while Rayforge is connected, Rayforge changes to an error state. This suggests the Smoothie Telnet driver is parsing FluidNC’s responses differently and doesn’t treat them as confirmation, even though FluidNC is accepting and executing $H. El mié, 11 mar 2026 a las 19:33, Samuel ***@***.***>) escribió:

…

*knipknap* left a comment (barebaric/rayforge#165) <#165 (comment)> Thank you, that clears some things up. There is actually a chance that your device can already work: By selecting the Smoothie driver instead a a Grbl driver. That communicates via Telnet, so it may work. The GrblNetwork driver cannot work because it relies on HTTP working, which FluidNC does not support. — Reply to this email directly, view it on GitHub <#165 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPITKQF6OUYQMGTYTK37BND4QGWO5AVCNFSM6AAAAACWMGSY3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANBRGI3TSNJTG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[knipknap]

Oh well, I think I will have to create a dedicated FluidNC driver to support this. I will try and look at this for release 1.3.

[chamusquino]

Thank you so much for your interest and time.

I'll wait for version 1.3 to be released.

Sorry I couldn't reply sooner.

[knipknap]

I am not sure why you closed the issue - no change was implemented yet. While a 1.3 release was made this was a quick fix release that we had to make in between, so the implementation may happen in 1.4.