Custom gcode not working with Fluidnc but standard GRBL OK

Dear Support Team,
I am seeking assistance with an issue involving LightBurn and FluidNC. Specifically, I am unable to get a “Custom Gcode” profile to function correctly with FluidNC, whereas the standard “Grbl” profile works without issue.

Issue Summary
When using the “Custom Gcode” profile, the console becomes unresponsive and fails to communicate with FluidNC upon loading or switching to that profile. In contrast, the standard “Grbl” profile establishes communication successfully and allows normal machine operation.
To enable the “Custom Gcode” feature, I updated to LightBurn version 2.0.04.

System Configuration
Operating System: Windows 11 (Core i7 desktop)
Serial Port: Single VCP (Comm3), no other software accessing it
LightBurn Instance: Only one running
Firmware: FluidNC v3.7.17
Hardware: Verified functional with standard “Grbl” profile

Observations
Using a standard “GRBL” profile, the machine behaves as expected and can cut files, confirming serial communication and firmware integrity.
I have used this setup successfully with older versions of LightBurn.
Despite extensive testing and profile adjustments, I have not achieved reliable communication using the “Custom Gcode” profile.
Online resources have not provided clarity on the correct configuration for FluidNC with “Custom Gcode”.

My assumption is that when using the “Custom Gcode” profile, some communication between LightBurn and FluidNC is either not displayed—even with “show all” enabled in the console—or is incompatible with FluidNC’s expectations.

Test Parameters for “Custom Gcode”
Flavor: “Grbl” or “Grbl M3” – no difference
Flow Control: Synchronous or Buffered – no difference
Enable DTR: No difference

Diagnostic Test Setup 1 – Standard GRBL
Default profile: “jczFiber”
FluidNC powered off
Launch LightBurn, power on FluidNC, wait for Windows chime and VCP availability (~15 seconds)
Select standard “GRBL” profile and choose port
Console populates with FluidNC startup information
Machine homes and responds to console input

Console output:
ok
[VER:3.7 FluidNC v3.7.17:]
[OPT:MPHS]
[MSG:Machine: 4038-BFL-12102025]
[MSG:Mode=AP:SSID=FluidNC:IP=192.168.0.1:MAC=EC-64-C9-0F-F4-75]
ok
[G54:0.000,0.000,0.000,0.000,0.000,0.000]

[MSG:Homed:Z]
ok
?
<Idle|MPos:0.000,0.000,150.000,0.000,0.000,0.000|FS:0,0>
ok

Diagnostic Test Setup 2 – Custom Gcode
Default profile: “jczFiber”
FluidNC powered off
Launch LightBurn, power on FluidNC, wait for Windows chime and VCP availability (~15 seconds)
Select “Custom Gcode” profile and choose port.

This test did not yield repeatable results. The following console output appeared once but could not be replicated. Other connection attempts involved USB reconnection or hardware reset. Even when the console shows output, the machine does not home or respond.
Console output:

Waiting for connection…
[MSG:INFO: uart_channel0 created]
[MSG:RST]
[MSG:INFO: FluidNC v3.7.17 GitHub - bdring/FluidNC: The next generation of motion control firmware]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.4]
[MSG:INFO: Local filesystem type is littlefs]
[MSG:INFO: Configuration file:4038-BFL4.yaml]

Grbl 3.7 [FluidNC v3.7.17 (wifi) ‘$’ for help]

Request
I would appreciate any guidance or recommendations on how to properly configure LightBurn’s “Custom Gcode” profile to ensure compatibility with FluidNC. If there are known limitations or required settings for this integration, please advise.
Thank you for your time and support.
Best regards,

I don’t understand this. If you choose grbl, there is no jczFiber profile. The fibers use a very different driver. What do you mean here?

Hello Misken,

I initially set the default profile to “Jcz Fiber” so I could always start LightBurn in a known working state without any claims to the serial port. From there, I would launch the FluidNC controller and switch profiles specifically for testing purposes. this was to ensure there was no rubbish stuck in windows buffers or the serial bridge chip on the Fluidnc board. when switching from Jcz Fiber to a standard “GRBL” profile i always got a functioning machine. When switching From Jcz Fiber to the "Custom Gcode " profile i would get different or no response from Fulidnc.
This would also happen form any profile or by setting the “Custom Gcode” as the default.
how ever you attempt to connect to “Custom Gcode” the response was never consistent of functional.

This setup is by no means how I would typically run a machine—my goal was simply to eliminate as many variables as possible during troubleshooting.
thank you for response Tf

Ah, ok. Now I got it. I can imagine that there is a difference in how the serial port is opened in both profiles, since LightBurns serial port implementation seems to be a little buggy anyhow. There is no clear pattern but I have users reporting serial protocol issues here and there over the last years…

Additional Information: Re Custom gcode not working with Fluidnc but standard GRBL OK

With the testing conducted so far, I have not made any changes to the default custom profile set up by LightBurn. Additionally, there are no start or end scripts configured.

If you want to dig even deeper, you can install a serial interface debug tool to compare the data that is transferred in both cases.

Hello Misken
Do you know of any programs as i thought that was not possible with virtual ports.
my soloution would be to solder on a wire and snoop with a terminal program.
Tf

Can you export the device profile for both your working device and the custom gcode device and post here for comparison? Or else review the files yourself to see if you can isolate a difference.

Subject: Additional Information Regarding Custom Profile Issue
Hi [Support Team],
Following up on the issue, I’ve attached the requested files. Please note that since the files were exported as a ZIP archive, I wasn’t able to perform a direct comparison.

For further testing, I created a new custom profile on a separate machine—a Dell desktop with a Core i3 processor running Windows 10, disconnected from the network. I installed the latest version of LightBurn and observed the same behavior.

When I run a standard GRBL profile, everything works as expected. However, when I load the CustomGcode profile, I get a response from FluidNC, but it will not home or respond to console input.
4038-GRBL-working.lbzip (1.6 KB)
CustomGCODE4038-notworking.lbzip (1.7 KB)

Let me know if you need any additional details or logs.

I see 3 notable differences:

  1. DTR signal is not enabled in the custom code. Change this under Device Settings→Basic Settings
  2. COM port is not configured in the Custom file. Make sure that you are actively selecting the relevant COM port in Laser window. It is sandwiched between the “Devices” and Laser Selection fields in that window. Your GRBL device is on COM 3. Make sure you choose the same on Custom Gcode
  3. You are using a “GRBL-M3” profile for your custom G-code. You may want to change this in Device Settings→Custom G-code tab.

Can you make these changes and retest please? Please report back.

Hello berainlb

I’ve changed the DTR signal.

I suspect the serial port wasn’t properly configured during profile export, likely because the machine wasn’t connected to the controller at the time.

In the Custom profile settings, I switched from GRBL M3 to GRBL.

I re-ran the test using the same procedure outlined in the original post.
Here’s what I observed:

The console window shows the initialization script from FluidNC.
However, the home function doesn’t work.
Typing ? into the console is ignored.

When I switch to the standard working GRBL profile, the machine homes correctly and responds to console input as expected.

I have included the updated profile

CustomGCODE4038-notworking-2.lbzip (1.7 KB)

Tf

I’ve used FluidNC a fair bit. It mostly behaves like GRBL hence, why we didn’t feel the need to create a separate Gcode flavor for Custom Gcode.

Which controller are you using?
Your version of FluidNC v3.7.17 is over a year old.
If you have the opportunity to update, it would be interesting to know if it makes a difference. (Save your machine config.yaml file first)

I’ll run some tests when I’m at the machine the next time!


If you really want to: Wireshark can be used to sniff USB packets. It has its own learning curve, to say the least.

You can look inside an exported .LBZIP by renaming it to *.ZIP. The contained .lbdev file can be opened with any text editor.

Uhm, What makes you say that?

I’m probably biased, but most comms issues can be attributed to faulty USB cables, drivers, operating system, or firmware.
Many oddities can be resolved by restarting the controller, or right-clicking the Devices button in the laser window to reset the USB connection.

I agree. Though during the last five years in support, I had quite some cases that I could not explain other than through USB library issues. Many cases where LaserGRBL could connect without any issue, but LightBurn did not work properly. And I’m pretty sure that there was a time a few years ago ( I’m not aware of recent / new cases) where LightBurn altered the firmware settings without user interaction. This happened quite often.

We also had one or two very detailed analysis of users here in the forum (I remember using usb debugging tools etc) to track down weird behavior in usb communication. I have to find them again. I’m not at home at the moment.

I would need to see the specific issue in order to investigate it. There are several variables here, such as baud rate, DTR signal, or other programs blocking the COM port.

I discussed this with a developer, and in our opinion, LightBurn only ever changes the $$ values via the “Machine Settings” or the console, never without user interaction.
If you can send a link to a post where this happened, I’d like to look into it.

Test Session 3 Update

I’ve updated the FluidNC controller firmware to the latest version as Aaron.F suggested.
Board: FluidNC 6x CNC Controller V1.2

Issue Encountered:
When switching from the “JCZ Fiber” machine profile to “Custom Gcode,” the controller only displays “Waiting for connection.”
After removing power and restarting (still in the Custom Gcode profile), Fluidnc sends the start up data shown below.
Sending $$ returned no response.

Troubleshooting Steps:

Switching to the standard GRBL profile and sending $$ worked as expected.
I downloaded a serial tool, but it won’t display the virtual port without a paid license.
Planning to connect via hardware terminal over the weekend to capture more detailed output.
Tf

fluidnc response while in Custom Gcode profile

Waiting for connection…
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13260
load:0x40080400,len:3028
entry 0x400805e4
[MSG:INFO: uart_channel0 created]
[MSG:RST]
[MSG:INFO: FluidNC v3.9.9 GitHub - bdring/FluidNC: The next generation of motion control firmware]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.7-dirty]
[MSG:INFO: Local filesystem type is littlefs]
[MSG:INFO: Configuration file:4038-BFL-3.yaml]
[MSG:INFO: Machine 4038-BFL-26072025]
[MSG:INFO: Board 6xx]
[MSG:INFO: I2SO BCK:gpio.22 WS:gpio.17 DATA:gpio.21Min Pulse:2us]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19]
[MSG:INFO: SD Card cs_pin:gpio.5 detect:NO_PIN freq:8000000]
[MSG:INFO: Stepping:I2S_STREAM Pulse:4us Dsbl Delay:0us Dir Delay:1us Idle Delay:254ms]
[MSG:INFO: Axis count 6]
[MSG:INFO: Axis X (150.000,530.000)]
[MSG:INFO: Motor0]
[MSG:INFO: standard_stepper Step:I2SO.2 Dir:I2SO.1 Disable:NO_PIN]
[MSG:INFO: Neg Limit gpio.36]
[MSG:INFO: Axis Y (-250.000,150.000)]
[MSG:INFO: Motor0]
[MSG:INFO: standard_stepper Step:I2SO.5 Dir:I2SO.4 Disable:NO_PIN]
[MSG:INFO: Neg Limit gpio.35]
[MSG:INFO: Axis Z (50.000,150.000)]
[MSG:INFO: Motor0]
[MSG:INFO: standard_stepper Step:I2SO.10 Dir:I2SO.9 Disable:NO_PIN]
[MSG:INFO: Neg Limit gpio.32:pd]
[MSG:INFO: Axis A (150.000,1110.000)]
[MSG:INFO: Motor0]
[MSG:INFO: standard_stepper Step:I2SO.13 Dir:I2SO.12 Disable:NO_PIN]
[MSG:INFO: Axis B (150.000,350.000)]
[MSG:INFO: Motor0]
[MSG:INFO: standard_stepper Step:I2SO.18 Dir:I2SO.17 Disable:NO_PIN]
[MSG:INFO: Axis C (150.000,350.000)]
[MSG:INFO: Motor0]
[MSG:INFO: standard_stepper Step:I2SO.21 Dir:I2SO.20 Disable:NO_PIN]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: STA SSID is not set]
[MSG:INFO: AP SSID FluidNC IP 192.168.0.1 mask 255.255.255.0 channel 1]
[MSG:INFO: AP started]
[MSG:INFO: WiFi on]
[MSG:INFO: Captive Portal Started]
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
[MSG:INFO: Laser Ena:gpio.12 Out:gpio.13 Freq:2000Hz Period:32767]
[MSG:INFO: Flood coolant gpio.14]
[MSG:INFO: Mist coolant gpio.4]
[MSG:INFO: Probe gpio.34:low]
Grbl 3.9 [FluidNC v3.9.9 (wifi) ‘$’ for help]
$$

Thank you for this report.

So far, I didn’t see an issue related to the Custom Gcode device type and FluidNC, using a Makerbase DLC32.

The fact that it works for you with the GRBL device type does indicate that we need a dedicated FluidNC Gcode Flavor in Custom Gcode after all!

I’m creating an internal report to look into this.


In testing some things on an undocumented ESP32 controller, I stumbled across a similar issue where I couldn’t send the controller any commands from LightBurn with either Custom Gcode or the GRBL device type.
(In my case, I had to disable DTR-Signal to get it to connect at all.)

The console spammed the message G0 and nothing happened when sending any $ command.
Can you enable “Show All” in the console and let us know if you see that too?

Are you using exactly this controller?

This page mentions a VCP driver that’s worth installing.


As mentioned, you can use Wireshark to sniff the USB traffic if you really want to. (It’s a bit of a rabbit hole, and the traffic can be hard to decipher but certainly exciting to see)

I know that it’s very unlikely, but the number of reports makes me suspect that this was the case. There were many reports, also here in the forum, but most of them are a few years old. It was back in the days when the S9 was popular, so around 2021/22 or so. I had many reports where the steps/mm were set to a different value than 80, and most of those users didn’t even know how to change firmware values.

Lately I didn’t see such posts any more. But I’ll let you know when I come across again.

Hello all,

I’ve connected a serial debug monitor on separate PC to the serial pins of the FluidNC board for debugging purposes. Here are my findings:
Test 1: LightBurn serial output with debug monitor.
lightburn profile Switched from JCZ to standard GRBL profile:

G0
$I
$#
?
?
?
?
the “?” continued at about 1 a second rate.

Test 2: Power-cycled FluidNC, switched from JCZ profile to custom GRBL profile
No output from LightBurn seen on the serial monitor terminal.(input to fluid nc controller)

Test 3: Power-up sequence with LightBurn set to custom GRBL
LightBurn started fresh

FluidNC board unpowered

Lightburn Console showed “Waiting for connection”

FluidNC board powered up

LightBurn issued ⸮⸮⸮ (Note character ⸮ count varied across repeated tests)

Lightburn Console output with “Show All” enabled:

Waiting for connection…
G0
ets Jun 8 2016 00:22:57
“” deleted to make post shorter""
[MSG:INFO: Mist coolant gpio.4]
[MSG:INFO: Probe gpio.34:low]
Grbl 3.9 [FluidNC v3.9.9 (wifi) ‘$’ for help]
G0
G0
? "Command sent from LB consol "
G0

At this point Fluidnc is non responsive.

Test 4: I saved a job to G-code using the custom G-code profile-
then ran that job using the standard GRBL profile. It executed as expected.
Conclusion:
There is a clear difference in the output between the custom G-code profile and the standard GRBL profile during the initialization phase.
Unfortunately my current testing method does not allow me to capture challenge-response interactions or establish a reliable timeline.
At this point, resolving the issue is beyond my capabilities.

Next question:
Is there any proven hardware/firmware configurations known to work reliably with the custom GRBL profile?
Tf

Are you using a genuine 6x controller from Bart, the creator of FluidNC, or a knock-off version?

At this point, I believe the ESP might be malfunctioning. Our cheap controller I mentioned earlier couldn’t be used with the FluidNC Webinstaller, which was peculiar.

Can you see if that’s possible with yours?
Use Chrome or Edge to go to this page: installer.fluidnc.com

The webinstaller should detect the firmware on the controller, allowing you to access the FluidTerm, see the config files etc.

After connecting and selecting the device in LightBurn, did you try


Absolutely!
I’m personally using both Makerbase DLC32, and the TinyBee controllers with FluidNC with the Custom Gcode device type.
@goeland is also using the 6x controller.