LightBurn v2.1.00 RC2 Release Candidate

Yes, that’s the closest way to describe it. But, when I click, select on or off “Show”, I expect it as a separate action and the focus is still on the selected shape. It makes no sense that the action focus “automatically” jumps from the on/off input field to the “Mode” drop-down where the arrow keys can still scroll through the 3 options. That effect occurs with or without a shape in focus/selected. The menus should be selected first before their function can be changed.

Furthermore, the color of the menu fields changes “uncontrolled”, sometimes the entire row is marked “active” which I consider correct, but the arrow keys can change the highlighting of a single, 2 or all 3 fields, (without activating/deactivating the field’s function)

There should only be one action at a time, when the function is selected and it should only apply to the selected function with its associated controls.
The arrow keys should not be able to be used as the tab key, that is the tab key’s job.
This malfunction is also seen in that you jump directly from “Show” to “Mode” with the up/down arrows and continue to cycle through the 3 options with the up and down arrow keys - (not with the L/R arrows).

The arrow keys should be used in the same way as in the top menu line, here you cannot cycle through the list either, you must actively select a function first before you can in some cases use the arrow keys for further action.

Sorry that I can’t express myself more professionally, but I hope it makes sense.

I’ve asked @Brodie, as a member of the Dev Team, for his comment and feedback on this one, @bernd.dk. :slight_smile:

1 Like

Crash report from today, when saving/closing LB.

Crashreport-250130.txt (73.6 KB)

I’m not a dev, but this part caught my eye:


Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x000000b4ffffff7d
Exception Codes:       0x0000000000000001, 0x000000b4ffffff7d

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11

And

|4   LightBurn                     |       0x106d7ab58 UndoDeleteShapes::~UndoDeleteShapes() + 168|
|---|---|
|5   LightBurn                     |       0x106d7ac4e UndoDeleteShapes::~UndoDeleteShapes() + 14|
|6   LightBurn                     |       0x106cd479f MinList::~MinList() + 47|
|7   LightBurn                     |       0x106d8c9bc 0x106cc8000 + 805308|
|8   LightBurn                     |       0x106cd479f MinList::~MinList() + 47|
|9   LightBurn                     |       0x106d89042 UndoSystem::~UndoSystem() + 18|

A segmentation fault happens if we are trying to access memory that isn’t valid anymore.

Can you list the last steps you took until it crashed as detailed as possible?

  • Did you save the project file previously, or was it a new project?
  • Did LB crash when you tried to close it?
1 Like

Yes, it was a “test” file, I was supposed to test some design… I’ve been pretty busy the last few days with some nice orders, so it’s been running really fast on the computer… if I remember correctly it was during the shutdown itself, after I chose not to save my session…
I’ll pay more attention to that next time.

1 Like

This might be an important clue!
Thank you.

1 Like

Hello everyone.

First of all, I wish you all a great 2026.

I’m still a bit busy, but I have to report these issues to keep Lightburn at the top:

1 - After using version 2.1.00-RC2 for a few days in the same Windows session (I usually hibernate the PC)
after accessing Settings, when I clicked on the X to close the window, Lightburn crashed.

LightBurn_Crash_Log_.txt (62.2 KB)

2 - A few days later, I was going to cut a job on the laser. When I went to select the correct COM port, Lightburn crashed again immediately.

LightBurn_Crash_Log.txt (61.0 KB)

Hi @parsec,

Nice to hear from you. Even for a bug report.

The first Crash_Log is from the version 1.7.04
Crashes related to letting the program run over a long time with hibernates involved are notoriously difficult to reproduce, but it’s possible that this one has already been fixed in the latest version.


Do you recall which of your many devices you were using here?
If you can reproduce this same crash, it would help us locate the issue if you could capture a Debug Log and sending it to support@lightburnsoftware.com


I confess: I peeked at your “Custom GCode for Plasma”, and the “WAZER” devices and see your elaborate device configuration and custom scripts.
Is everything working to your expectations?

If you would like to share details, I would be thrilled to read an article about it! :slight_smile:

1 Like

I observed the same behavior on a windows 10 machine today, in a remote session on a computer of a friend in Australia.

Would it be possible to place the input cursor at the start position when activating for entering new values?, preferably on all the fields that act in this way. Having to clear the old values ​​before entering new ones is not practical.

Everything is possible. But you can already do these things:

  • use the left and right arrow keys on the keyboard to move the cursor
  • place the cursor where you want with a single mouse click.
  • double click to select each number until the comma
  • triple click the entry box to select everything
    LB_Entry-box-select

Does that work for you on MacOS to achieve what you are asking for?

Thank you Aaron.

WTH, I just noticed that LOG 1 is from January 24, 2025, which means that Lightburn did not write the crash file on the first error. I searched the system to see if it was somewhere else, but found nothing.

The laser in use is the -GRBL-M3_to_M4.
Many of the other profiles were created to check the output and thus try to help other forum users.

I have tried to reproduce the error with similar steps, but it did not happen.

That’s not exactly what I was thinking, but a little faster than deleting the existing content manually before being able to type a new value.
My idea was more of a click in the data field and then typing new content, without detours.
But, the triple click function is a useful compromise :wink:

Thanks for the response

Yes, when the numbers are selected, you don’t need to press the delete button. Typing anything does that for you.

1 Like

1 - Before 2.1 sometimes when opening a new window the camera output goes to the new window and after closing don´t return to the first window, Don´t know if this is already fixed or it´s random but it´s not happening now.

2 - Three time in a row I double-click an entry on the Cuts/Layers window and it took 10 seconds to open the Cut settings editor.

Forgot yesterday: 2.1 has set a very unusual Fast White scan speed of 59mm/m.

LightBurn hangs in a loop and can only be terminated with the kill command.
(in preview, see image)
Window 10, LB RC2

I just tested the quick nest feature with a (ok, difficult) task, and it failed (manual positioning on the right):

I know it’s not the easiest algorithm, but I still wanted to show this kind of case.

1 Like

Hi Bernd,

I was unable to reproduce exactly what you describe with “hangs in a loop”.
Can you make it happen repeatedly, and what are the exact steps you took?

Did you try changing the Machine Layout here?

You might need to decrease the “Pattern Size” here to make it fit on the workarea.

It still should not “hang in a loop”. Please share more details on what you mean by this.

I did find something related and forwarded it to Jeremy to take a look.

1 Like

Can you send us the .lbrn2 file you are working with here?

I agree that the crosses should fit in this bounding box! But the algorithm doesn’t seem to be testing all possible placement variations yet.

We are still working on refining Quick Nest and making it smarter.

I’m afraid that might be the best it can do at the moment. But I’m looking forward to reviewing your file and forwarding it to @girish

That’s the biggest understatement ever :slight_smile:
Nesting is surprisingly complex, and some of the industrial solutions are priced in the five-digit range.

2 Likes

2026-02NestingChallenge.lbrn2 (102.0 KB)
Here it is.
Yep, I know, nesting is a really nice computational problem :slight_smile: I was surprised that it’s really that fast right now.

1 Like