When I am etching on my laser it is drawing a bunch of lines when I am using “Fill”. This is ruining the job as the text is virtually unreadable. To get around this I am using Offset Fill, and that seems to work out, but this is sometimes impractical.
I am creating the job files using my MS Surface using Windows 11, then running the job on my Raspberry Pi. Is there a setting I need to set on the RPi, or is this a problem with running a Windows created job on Linux? Any help would be greatly appreciated.
See the attached pics as reference. (The “bad” ones are using Fill, and the “good” one is using Offset Fill)
This type of issue doesn’t seem like it would be something Pi or LightBurn related.
Have you validated that the issue is exclusive to running on Pi? Is it possible the problem would also be present if burning with the Surface?
If you’ve already confirmed this can you take a simple design where the problem occurs and go to File->Save gcode, save with .txt extension and then upload the file here?
I tried from my MS Surface running Windows 11, and all is good. I tested the print … the only difference being the rig it was etched from, and the RPi has the weirdness, but the Win 11 does not.
I will include the following as evidence:
Image of the test etchings
gcode for both RPi and Win11 (extension changed to txt)
Preview images for both RPi and Win11 (even the Previewer sees the lines on the RPi)
That’s quite telling. At least the problem is apparent in LightBurn so if it can be resolved there then the issue should go away.
Does this occur with all fill operations or is it somehow unique to this job?
Is the “The Christmas Story” portion of the design a text object or has it been converted to a path? If a text object, try converting to path to see if that changes the outcome.
If so, then it could be a font rendering issue.
If not a text object, can you upload the .lbrn file here for review? I’ll try to recreate the issue.
I have tried it with bot text and path objects, and the same thing happens to all of them.
The Christmas Story is a path object, but it happens to text as well (I can change something to text and run a test for you if that would help)
Let me know if you need anything further from me on this.
Thank you so much for looking into this issue … it is more annoying that anything else, but sometimes Offset Fill is not the most efficient method of filling … so I thought I’d bring it to your attention.
Here is the “real” .lbrn2 file (the test file got deleted by an automated process I have running on my system, but this one has the same issue): Christmas Story Storage Box.lbrn2 (227.3 KB)
Are you using the guide that I built for Raspberry Pi setup or did you stand this up on your own? Trying to see where the source of the problem might be.
Thinking back when I tested this with a Mayan calendar I saw some strange artifacts that I thought were part of the original design but I now suspect was related to this issue.
However, I don’t recall seeing this in my original POC so this may be a regression of some sort in one of the compatibility layers but not certain where.
Not sure if I’ll be able to troubleshoot this as doing so on my Raspberry Pi 3 with 1GB of RAM is painfully slow if I try to run anything besides only LightBurn.
It turns out that I did follow your guide using Box64.
I am running this on a Pi 400 unit (keyboard and Pi all in one)
I did have some issues with getting the right libraries, as many of them were just not available that I could find, so I run mine with the BOX64_ALLOWMISSINGLIBS=1 box64 ./LightBurn command. Other than this issue with the lines in fills, things seem to be working great.
I sync my .lbrn2 files to a NAS I have, then access that NAS from the RPi.
Did you follow my latest update to that post? It includes 2 packages with Libraries and a launch.sh file which should allow you to run without the missing libs variable.
I likely won’t spend time trying to address this unless I happen to get a newer Pi or there’s a major change to either OS, LightBurn, or packaging. I may experiment with the AppImage version once that’s stabilized.
