LB is double sending commands (now with video)

LightBurn Software Questions
, , ,
1

Having a strange issue where lightburn is sending all gcode in duplicate. If I look in the console, I can see the gcode for a move command appear twice (ie move x +50 and the gcode to do that task will be sent twice as can be seen in the console).
This is the same on a fresh install on 2 different computers (Same laser though).
Any ideas on what to check would be much appreciated.
LB Console

I should add that not only jogging, but also does framing and actual laser job twice as well. Also LB v 1.5.06 on Windows 11

Also also, tested using ioSender and it only sends the jog commands once.

Here is a link to a video of the issue.

The rabbit hole deepens: tried my Cohesion3d based laser and it didn’t double, no big surprise there. Then tried my small gantry diode controlled with a grbl 1.1f controller. Made a new profile for it and it worked fine. No doubling. Tried my k40mod laser with the same profile and double movements on the new profile and the old one.

2

Do you use continuous jogging or single jog commands?

3

That’s set on single jog

4

I never experienced that yet. Did you add the laser as plain grbl device?

5

Yeah. According to the grblHAL documentation, it behaves as a grbl 1.1 controller. It’s definitely something on the lightburn side since ioSender doesn’t do the double sending. Going to make sure that my Cohesion3d based laser behaves properly when I get off work and also test my small, vanilla grbl driven diode machine and see if it does the same thing or not. I’ll also post a video of what’s going on. It’s really weird that every action (except the macro buttons) double sends- framing, jogging, and jobs.

6

The end of the video was supposed to show the settings, but the capture software was only set to capture the main window. sorry bout that. If you need to see a particular setting, let me know and I’ll upload a screenshot.

7

Would it be possible to share a bit more information
a) Screenshot of the Edit > Device window
b) the same project you ran, or a similar one, can you click Save Gcode
And upload the gcode file please

8

devicesettings
devicesettings835×832 42.1 KB

machinesettings
machinesettings915×1015 37.9 KB

testgrbl.gc (260 Bytes)
You also reminded me of another thing I needed to test. The attached gc isn’t the one from the video, but if I save the gcode then tell it to run gcode, it only goes once. If I don’t do anything to the setup and just hit start, it goes twice.

9

TO make sure i got all variables correct

  • this happens on 2 computers with the same machine correct?
  • it happens no matter what project you set. RUns > runs again
  • But it exports correctly the Gcode

i was thinking maybe your space bar was being pressed and it would trigger a 2nd run but that would mean it would have to trigger it continuously.

Cant think of a scenario on where this would make sense
Any chance you could downgrade - for sanity checks - to maybe 1.4.03 or 1.5.06 Releases · LightBurnSoftware/deployment · GitHub

And confirm if the same happens?

10
  • this happens on 2 computers with the same machine correct?
    Yes. A desktop and a laptop connected to the same machine. Other gcode senders (ioSender) work fine without double actions.
  • it happens no matter what project you set. RUns > runs again
    Jogging, framing, or running the job in the video all result in double action. Using the run gcode button after saving it then selecting the saved file will run once without doubling.
  • But it exports correctly the Gcode
    It appears to be fine.

For my Cohesion board and the woodpecker grbl based machine, there is no doubling issue. Only with the grblHAL based machine.

I can try 1.4.03. I was on 1.5.06 when I first started testing the machine (on 1.6 now). I’ll probably have to give that a go in the morning for me. I’ll post again when I have a result from that.

11

I think I have a BTT SKR controller for testing


I have LightBurn 1.6.00 up and running on Windows 10.
I will attempt to reproduce the behavior.

3 Likes
12

In the Video I noticed that ‘Show all’ is selected.

LightBurn won’t usually display what it sends unless that switch is selected, If you turn off ‘Show Selected’ and repeat the test, one of two things should happen.

You’ll see only one copy of the sent commands, showing that the controller is echoing what LightBurn sends. This could be normal. Still investigating.

*Note: Controllers are occasionally set to Echo the commands sent. There’s probably something in a config file to turn Echo off. I hope this isn’t an option that’s limited to Build-time (when the firmware is compiled and flashed into the controller).

or


You’ll see zero copies of the sent commands, showing that LightBurn was sending both sets of commands and that neither will be shown under this circumstance.

My BTT SKR (Pico) controller doesn’t seem to have any firmware on it - fresh out of the box. I’d like to know which firmware version you have on your controller.

If you scroll up in the Console window you can reach the initial connection message which usually contains the Build date and Build information. I can see part of it in the video but it’s not enough to confirm the firmware version.

Please Scroll back (up) in the Console window in LightBurn, select and copy the text (with the firmware build information, from where you first connect to the controller with LightBurn) and paste it into a reply here.

Also, Something else that may help,

In 1.6.00 LightBurn moved the Preferences Menu. Click File, click Preferences, then click Export Prefs and save that file locally and somewhere convenient.

If you’re willing, please drag that file into a reply here. I may be able to find out more about the Firmware and the settings.

13

[VER:1.1f.20240228:]
[OPT:VNMSL,100,1024,3,0]
Target buffer size found
[AXS:3:XYZ]
[NEWOPT:ENUMS,RT+,HOME,ES,SED,SD]
[FIRMWARE:grblHAL]
[SIGNALS:HSEP]
[NVS STORAGE:*EEPROM 4K]
[DRIVER:STM32F103RC]
[DRIVER VERSION:240220]
[BOARD:BTT SKR MINI E3 V2.0]
[AUX IO:2,0,0,0]
[PLUGIN:Trinamic v0.15]
[PLUGIN:SDCARD v1.13]
[PLUGIN:FS macro plugin v0.07]
prefs.lbprefs (36.8 KB)
show all off
The screen shot shows what happens during a jog with “Show all” off in the console.

The PICO is a pi based controller vs the STM SKR Mini E3 V2 that I am using so I’m not sure it’d be able to reproduce the same behavior. I used the web builder for grblHAL to build the firmware I used (also available for the pico)

1 Like
14

Another thing that I noticed is that while it moves twice, the current position coordinates only update to show one of the moves (ie jog x+50, coordinates show the position as x50 after the doubled jog)

15

I have an SKR PICO as well and tested and got the same result with the firmware generated by the web builder. Here is a link to the firmware file in my google drive.

1 Like
16

seems to me - but i speculating - something in your web builder is not matching right your hardware

Could you burn into the board a precompiled firmware - even if without laser functionality fine tuned just to be sure you can - or not - replicate behavior?

That would tell us a lot and close down the variables

18

The web builder was created by the group that develops the grblHAL project. There are no precompiled versions provided that I’m aware of or could find as it’s an open source project that supports a lot of different boards.

19

Granted, what i was suggesting is reduce variables to a common denominator
if you were able to flash the board with a known bin - even if for an 3d printer - and you were able to control the machine steppers only.
You could validate if
a) DO the problem of repeat happens still
b) no problems on motion

Then we can for sure be able to pinpoint on a configuration issue on firmware

20

Unsure if this can be of any help - i do not know the hardware so i am just guess estimating and trying to think out loud diagnostic steps i would probably do.

21

My mistake. I forgot that LightBurn works with marlin.It seems to be an issue with how LB talks with the grblHAL since I can use ioSender and it doesn’t double the actions. It also did the same thing on a RPi based board I tested on.

I just tested it with Marlin firmware and it behaved normally (no double actions)