Still Big Problems With Tabs/Bridges

A couple years ago I made this post talking about a bug when using tabs/bridges with a layer that has a kerf offset.

I’m still having issues with tabs/bridges and have found even more strange behavior.

Firstly, it seems the cut preview shows where the tabs would be without taking the kerf offset into account. I personally strongly feel that it should show where they ultimately will be taking the kerf offset into account. Heck, maybe the whole cut preview should show the actual final cut, or there should be an option to switch to the final cut view (I know the calculations can be pricey). It’s sometimes very important to know where the tabs will be especially when making breakaway puzzle boards like I make since some parts have fragile areas. See below, the cut preview doesn’t match the actual output preview.


tab bug D20 preview

Besides that and more importantly, the cut tab preview is just wrong after a certain spacing. In my case, when I increase the tab spacing up to the point where there are exactly 3 tabs on each shape (36mm in my case), the preview doesn’t change any more if I keep increasing it. 37mm shows exactly the same as 36mm. Even 100mm still shows 3 tabs, exactly in the same position as 36mm spacing. This doesn’t make sense. If I go to the actual output preview, it shows where the tabs will actually be. See pictures below.



In my opinion, the tabs should be calculated after kerf offset so it will show you where they will actually be, or at least there should be an option to show the final positioning of the tabs when in the cut editing window

Actually after testing a little more, it’s not just that it doesn’t take the kerf offset into account. That would only change the tab placement slightly (the kerf offset for this layer is only 0.083mm). However, I have it set to exactly 3 tabs per shape, but in the actual preview it shows only 1 tab per shape, which is way off. Something deeper must be going on.

By the way, if you are looking for more developers, I am looking for work currently and I’d love to tackle this issue :sunglasses:

Here I made a stripped down version of the file to show the issue. I removed most of the content since its valuable IP for me but left one piece that exhibits the issue. When you look at the tab placement using the tab tool or editing the cut it shows 3 tabs per piece, but when you do the actual preview, it shows only 2, and they are way further apart.

If you edit the cut and switch it to spacing instead of number of tabs, you can see that if you increase the spacing past 36, nothing changes in the tab preview. It always shows 3 tabs evenly spaced.

Here is the file:
Lightburn tab bridges bug puzzle piece.lbrn2 (15.1 KB)

Thank you for mentioning this again. The internal discussions have restarted around this issue. @adammhaile is now living in a different country, where it is currently Friday, past midnight, his time. I suspect he will chime in shortly. :slight_smile:

1 Like

I’ll take a look. Thank you for the file @AlteriusOmega
One thing I will note: The automatic tab generation was never meant for when you needed precise control over the tab locations. It’s a best effort calculation based on the shapes given and there are a lot of things about various shapes that can affect where they land and how many there are. If you need precise control I always recommend manual tab placement (where they show up as red in the edit window preview). You can easily convert automatic tabs to manual either in the cut settings panel or by simply selecting the tab placement tool and move some of the existing automatic tabs. They will turn red to show that they are now manual.

As to not going above 36mm spacing, that’s working exactly as designed. I checked your file and the perimeter of that shape is 108mm (you can use the Measure tool to see this).
108 / 36 = 3. And you have the minimum number of tabs set to 3. So once you reach 3 tabs and further increase in spacing will be ignored because that would decrease the number below 3. Apologies is this was unclear from the docs.

Regarding kerf, I will have to look into this. No, it does not take this into account at the moment. This was honestly intentional since with the typical size of a laser kerf it shouldn’t actually matter. Though, as you noted, in the final output they are in the wrong place. I can confirm that is of course wrong and I will check on it.

1 Like

I’ve fixed the missing tab issue for the next release. Still looking into if showing the kerf in the edit window preview is even possible. As you noted, it’s a lot of math and would be pretty slow.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.