LightBurn running on Raspberry Pi - Now working

Good news, everyone! This has been often discussed but never realized, until now.

[EDIT 2023-11-25] The instructions in the first post are old. Refer to post 32 for updated instructions and library archives.

LightBurn running on a Raspberry Pi:

I had theorized that this was possible and wanted to see what it would take for this to work.

Note that this is not a tutorial. This is a proof of concept and as can been seen from the screenshot I only got as far as the activation screen. I’m posting this to get others who are well interested and able to move the ball forward to get involved. This is not ready for users to get involved as yet.

Having said that, here’s what it took to get there.

  1. Install 64-bit Pi OS with Desktop. I ran the release from “September 22nd 2022”.
  2. Install box64 - GitHub - ptitSeb/box64: Box64 - Linux Userspace x86_64 Emulator with a twist, targeted at ARM64 Linux devices
  3. Download LightBurn for Linux. I used the 7zip version.
  4. Extract LightBurn and enter the LightBurn directory
  5. [EDIT] Add missing libraries as documented in Post 8.
  6. [EDIT] Run LightBurn using this command: “BOX64_ALLOWMISSINGLIBS=1 box64 ./LightBurn”
    Run LightBurn using this command: “box64 ./LightBurn”
  7. Profit

Notes:

  1. I ran this on a Pi 3 with 1GB of memory. This was painful. Do better. LightBurn itself came up relatively quickly so it looks promising.
  2. The reason for the odd “BOX64_ALLOWMISSINGLIBS=1” is because without it I was getting an error about not being able to load a “libpulse-mainloop-glib” library. I couldn’t sort out why this was happening and this is actually what took me the longest to get past. I assume this is a library for pulse audio. Setting the environment variable seems to get past this without issue but I suspect audio wouldn’t work although I’m not sure if I’ve ever heard audio from LightBurn.
  3. As stated I got stuck at the activation screen. Attempting to activate resulted in a message about not being able to connect to the server that I didn’t capture a screenshot of. I assume this is related to unavailability of libssl1.0. However, I tried loading a deprecated set of packages without success. This is as far as I got with this so haven’t confirmed other functionality.
  4. Activation doesn’t seem an insurmountable issue. The critical hurdle will be making sure that devices can be loaded and seen from LightBurn. I suspect this won’t be much of a problem with IP based devices. For USB we know that Pis can connect to lasers without too much fuss so there’s every reason to believe this should work as long as LightBurn can see the Serial TTY devices. I confirmed that LightBurn can read and write to the filesystem by using the “Offline Activation Requestion” button. It worked without issue.

Anyhow, I look forward to others reproducing these results and getting past the remaining hurdles. Enjoy.

[EDIT]
Known Issues:

  1. Server based activation does not work
  2. Camera crashes and segfaults LightBurn
4 Likes

I got a new PI 4 for xmas… I’ll try and load it on that machine when I get some time …

Running under an emulator … I suspect on a 4, more speed will make it not so painful…

Nice job…

:smile_cat:

Thanks, Jack.

For me it was more the attempting to use a browser and task switching which was the painful part. I ended up downloading everything through the command line to avoid this but was difficult while troubleshooting.

With just LightBurn running the performance doesn’t seem so bad. It takes 35 seconds to startup but I can move and resize windows and that happens fairly quickly. I suspect for simple designs it wouldn’t be a terrible experience even on a Pi 3. On a Pi 4 this should be quite usable.

Box64 will use native binaries for many core libraries by mapping functionality so performance is a priority for the project. From what I’ve seen it’s mainly used for playing games so performance will be front and center.

I’m still stuck on getting server connectivity for activation. I’ve tried a few hacky things to get various versions of libssl loaded but no luck so far. I’m hoping someone with more familiarity with Pi, emulation, and running multiple architectures can pitch in.

I suspect running an offline activation would work but that feels a bit like cheating.

I’d cheat and see if you can raise the dead… You can figure out the ssl stuff at another time.

You need to get it up and send/do a job…

Do you happen to own a fiber…? the ol’ lady gave me a green light on one, depending on our tax returns … but it looks good.

:smile_cat:

2 Likes

Went down this road as I got stuck with resolving the connection issues.

More good news to share. So I was able to process an offline activation and LightBurn activated without fuss.

After activation, most things are surprisingly boring. I haven’t used LightBurn on Linux previously so can’t directly compare but everything worked for the most part. I had to resize the toolbar and font size, and collapsed the window panes to a single pane to get things to fit. This is likely because of the 900 vertical lines of resolution that it’s running.

For your viewing pleasure:

The inaugural burn:

Additionally, I tried running a camera on the Pi and it proceed to segfault. This may be related to the pulse audio library issue not satisfying something with the QT multimedia library.

So for now I declare this a partial success.

As for next steps I think it would be nice to resolve these two issues:

  1. pulse audio library not loading
  2. server connectivity

I would invite anyone with some skills in these areas to get this configured and to see if we can overcome these issues.

[EDIT] - one additional note on performance. Once running, performance was shockingly tolerable even on this humble 1GB Pi3. I wasn’t doing anything crazy but navigation and other basic tasks were only mildly slower than my daily driver. Processing times were slightly longer but nothing intolerable. I see this absolutely being usable as a “sitting in the shed next to the laser” type of solution.

1 Like

Very impressive, I’m in line as one of your first customers :wink: :+1:

2 Likes

Wanted to provide an update on this point for anyone that’s following this. I’m now convinced that this is not related to the openssl issue that prevents update checks from working. I confirmed that LightBurn could activate on a relatively fresh install of Fedora 37 that does not have any unsupported openssl libraries. Update check still failed.

So there’s likely something else going on.

Some possibilities:

  1. another library that’s required is not loading properly or otherwise incompatible
  2. networking issue - this doesn’t seem likely as all other network functions work correctly but can’t rule it out.

More progress today. Bottom line, LightBurn now comes up without needing to ignore missing libraries. As a bonus, the update check now seems to work.

I now understand that the reason this was not loading is because box64 has not wrapped the native version of that library. That means that an x64 version of that library needs to be made available.

I successfully located an x64 version of that library which allowed me to get past that error. However, it revealed further dependencies that needed to be resolved.

All in, I needed to locate x64 versions of these libraries:

libapparmor.so.1
libasyncns.so.0
libdbus-1.so.3
libgstpbutils-1.0.so.0
liblz4.so.1
libpulse-mainloop-glib.so.0
libsystemd.so.0
libwrap.so.0
libzstd.so.1

The proper way to install these is likely to work with the package manager for your distribution and to load them through the packages. Instead I hacked this by placing the libraries adjacent to the LightBurn executable.

I will upload a copy of the library files I used but be warned. I am not to be trusted. These are binary files and could wreck havoc on your system. I am likely up to no good.

These files were taken from an updated version of Ubuntu 2020.04.05.

LB_box64.tgz.txt (2.2 MB)
[EDIT 2023-11-25] This is now obsolete. Refer to Post 32 for an update.

I was hoping that this would resolve the server based activation but it still does not work.

Opening a camera still causes a segfault.

1 Like

I’ve got most of the things installed… Box64 seems to have ‘installed’ but I see no icon, it lives in user/bin

Haven’t got the ‘box’ up to try and install lightburn…

:smile_cat:

I don’t recall seeing any box64 app icon but haven’t really looked. I’ve been running exclusively from command line.

Try running box64 from the command line. If you get a response that means that it should be working. In fact, if things are properly installed you don’t need to actually explicitly call box64 when running LightBurn. Running an x64 elf binary should be enough to automatically run box64.

Are you using the .run or .7z package?


Kind of busy… the spousal unit has allowed me to purchase a fiber laser, which I ordered this morning… :crazy_face:

:smile_cat:

.7z package. Although I examined the contents of the .run version and they seem identical. Just doesn’t setup the desktop icon and copy the files to .local.

berainlb : let us know when you are read to sale copies. I’ll place an order for 4 copies as soon as your ready. I have 4 PI-4B’s just sitting here starving to death !!
Randy

Don’t just sit there… load one of them up and help us get this working… :crazy_face:

:smile_cat:

Really impressive job. Thanks for sharing. Onestly i was hoping that lightburn developers release a native build for rpi and arm in general. Or at least a robust API or other communication way for using RaspberryPi as “printserver” like octoprint for 3D printing. This is the way I prefer: draw and produce gcode on powerful workstation/notebook the send gcode to SBC that perform job.

There are people using Octoprint today for laser cutting.

There are also methods of setting up a virtual USB port through the Pi allowing for wireless communication.

This has been discussed before. I do believe there’s long term plans to introduce native ARM builds but I understand that some of the libraries they use do not have ARM builds at the moment and right now, frankly, there aren’t many desktop based ARM solutions in the wild.

1 Like

Jack: you forgot I’m not an IT person. I know ladder logic, not this IT stuff. Here is a sample of what I know and understand.
Screenshot 2023-01-28 at 17-59-00 Ladder Diagram Example - ET438B-7.pdf

SO if you want my help, (LOL), someone is going to have to teach me 20 to 40 years experience in, (as you said), in a couple of hours. As for now, I’m trying to learn this programing stuff.
Randy

I wonder why LightBurn won’t just build for ARM(64) in the first place and be done with it. If they package it as flatpak, it’ll run on everything with the matching architecture. Everything would be easier for us customers and not that much work for lightburn, after all. Soon, Risc V machines are coming too and with them around, you’ll want your software to be ready.

So please, LightBurn. Can’t you just build for more platforms? Also, instead of using a bash script to install, flatpak does the same, only insanely better.

Read my post a few messages up. Apparently there are external dependencies for this that have not yet been met. And I’m sure competing priorities.

I’d expect Mac ARM to be the first supported ARM platform as that’s likely to be the most easily supported and impacting the largest user base.

In the meantime, time to get creative.

I didn’t know Mac had a new cpu in their lineup…

:smile_cat: