This is interesting, but 90% of firmwares of current laser engravers are forks of GrblHal so if LightBurn somehow wasn’t compatible with GrblHal that would be known.
Unsure if you tried this but, what happens if you SAVE gcode on lightburn → then run it in lightburn too
“Run gcode” button Will it double run?
What if you send that gcode via ioSender?
Admitedly if lightburn were to issue the same twice, it had to be baked in the Gcode.
I think you’re thinking of vanilla grbl, not grblHAL. grblHAL is a rework of grbl allowing for it to be run on 32bit processors.
I tested saving the gcode and then running it and it did not double the loaded gcode. (as discussed in a previous post)
Yes, I am familiar with what GrblHal is, and 90% of current machines use it as a base of their firmwares. Is very uncommon to have a vanilla GRBL firmware these days.
This confuses me greatly. i cant imagine a scenario where Lightburn could stream the Gcode twice - but more importantly correctly - and Not export it.
Puzzling indeed.
I didn’t know it was that widespread. All the hobbyist machines I remember that ran on grbl had an 8bit grbl board, but I haven’t really looked around at grbl based machines in quite some time so I guess I shouldn’t be surprised things have moved along.
So some more fun information:
If I enable $J jogging, jogging will not double, but it hangs as being “busy” after the move.
This does not effect framing or lasing. They still double.
I also tried inputting the gcode used for the non-$J jogging into ioSender and it did not double move.
Which compatibility level did you set in the web builder? (Compatibility level · grblHAL/core Wiki · GitHub) Try to set it to 3, just to rule out issues with the protocol stack.
I noticed that and went through each of the settings for compiling a couple hours ago, but it didn’t change the behavior. (0, 1, 2, 10)
Something that I noticed that might be related but in a different way:
I was also experimenting with grblHAL lately and I experienced many connections issues using LightBurn. LaserGRBL can reliably connect to the firmware (manually compiled grblHAL for MKS DLC32 board) at any time. There is absolutely no issue. But LB only can connect once in about ten tries. In my experience with earlier Sculpfun firmwares, I used to toggle the “enable DTR signal” option to cure this. But in this case, I’m toggling it a few times and do reconnects multiple times until LB will connect, and there doesn’t seem to be a pattern.
This underlines my impression that the serial protocol implementation still seems to be a little but more unstable than in LaserGRBL. We had a long discussion about this already a few months ago, but it didn’t lead to any conclusion, as far as I remember.
Interesting. From what i know LaserGrbl has 2 protocols for serial coms
I remember having a chat with Diego years back and he mentioned USBSerial 2 was the most stable, but i never got to understand why.
As @JohnJohn has the same board, maybe @Nick_Makin could upload the bin firmware file and John could try to replicate the issues?
I uploaded the firmware onto a google drive that I linked of firmware for the PICO that I had the same doubling issue with in an earlier post. (though the board I’m using in the machine is an SKR Mini E3 v2) When JohnJohn mentioned he had that board, I tested it as well.
I’m up and running LightBurn 1.6.00 on my Win 10 Device, with the firmware linked in post #15 flashed to the BTT SKR Pico 1.0:
Waiting for connection…
[VER:1.1f.20240427:]
[OPT:VNSL,100,1024,3,0]
Target buffer size found
[AXS:3:XYZ]
[NEWOPT:ENUMS,RT+,NOPROBE,ES,SED,RTC]
[FIRMWARE:grblHAL]
[SIGNALS:HSE]
[NVS STORAGE:*FLASH]
[FREE MEMORY:217K]
[DRIVER:RP2040]
[DRIVER VERSION:240408]
[DRIVER OPTIONS:SDK_1.5.0]
[BOARD:BTT SKR Pico 1.0]
[AUX IO:2,0,0,0]
[CLUSTER:16]
Cluster size found
[PLUGIN:LightBurn clusters v0.06]
[PLUGIN:Trinamic v0.16]
ok
I found the command to request the advanced settings from grblHAL.
$help settings
I have a bare board on my desk. It took some time to turn off automatic homing, Invert the Normally Closed limit switches $5=7 (absent) and Invert the Feed Hold, Start Cycle and E Stop switches $14=70 (also absent).
I selected Grbl-STM because the USB communication seemed better.
I had to use the Stop button in the Laser window to get past Error 9 on startup and unlock the controller.
I am having the opposite problem. I have no GCode shown in the Console window with ‘Show all’ selected. I am seeing no duplication of the single circle, I drew as a test, in the GCode.
If you’re willing to share the Project file publicly you’re welcome to post it here. I’ll test to see if it produces duplicates. If you’d rather not share, you’re welcome to send it to me Directly here. I’m willing to test your file and keep it private.
If sharing the file is out of the question, please start a new project with the settings that you have currently, Draw one circle in the work area, and save the project file (it should be an lbrn2 file). Test it to confirm the unwanted behavior and post that here.
I’d like to make sure it behaves identically to what you’re seeing, then pursue the next step.
I continued with my grblHAL-project and compiled a new firmware for a Sculpfun mainboard (was using an MKS DLC32 before). This binary / board does not have any issues in USB communication as the DLC32 had. I will try to further investigate what the cause could be.
If you need some additional testing, I also have a few boards (and some more) at hand to do some testing 
Also built a small laser simulator to be faster
@Misken (Melvin) That’s a pretty fantastic-looking setup… Thank you for sharing your insights!
I was advised to restart LightBurn. With ‘Show all’ selected I see and produce only one copy of my single circle test as expected with the recommended Firmware (above) on the BTT SKR Pico.
Thanks for looking into this. I will test on my setup and see what it does when I get a chance and let you know what my results are. If it’s this simple, that’d be amazing.
That’s an awesome setup you have there. That’d be pretty handy for getting your controllers configured and make sure they work before slapping them on your machines.
I was able to test on my PICO and switching to grbl STM fixes the issue. I’m not immediately near the machine with the other board in it, but once I am able to confirm the fix works there, too, I’ll update the post with your post as the answer.
Thanks for looking into that. That was the one setting I didn’t even think about since I read somewhere that for someone to get grblHAL to work with lightburn, they just selected the “grbl” option.
The plain Grbl setting was giving me a hard time. A couple of odd connect vs. idle states.
The STM was a lucky guess on my part. STM32 is for faster 32 bit controllers. Although it’s not really an STM chip, the RP2040 is 32 Bit ARM architecture. I figured that it was worth a shot. I tried it, and had empty looking communication (even with Show all) until I restarted LightBurn. Seems fine now.
That’s interesting. I wasn’t sure what the difference was with the different grbl options. I figured they were for specific branches and wouldn’t play nice, but glad to have been mistaken. Once I get a chance to confirm on the machine in question, I’ll update the post here.
I was able to confirm that the fix also worked on the BQ Mini E3 v2 board. Thanks for all the help in getting this figured out!
