Which version of the LightBurn installer did you start from?
Following post 32 I installed the current box64. I then use LB 1.4 7z. Thinking that that is what you assembled the instructions for. Once I got autoupdate turned off in the prefs.ini file 1.4 worked just fine. Then I repeated the setup with the 1.6 LB 7z file. I renamed the folder for 1.4 so I can distinguish between the version iām launching (ie Lightburn/ Lightburn014/). However, this time 1.6 opened first try.
This is indeed correct.
Perhaps it was a one time thing.
Iām more curious about the corrupted toolbar icons. Based on your screenshot it looks like youāre running at 1920x1080 which Iām pretty sure Iāve run without issues.
Can you confirm how you are connected to the Pi? Are you directly plugged into a monitor and keyboard or is this going through VNC or something similar?
Iām currently connected at 1080 with a micro to standard HDMI adapter, a HDMI to VGA adapter, VGA cable, monitor. I got the same display on another monitor directly connected with a Micro to standard HDMI cable. So nothing but cables and adapters.
Be aware that Iāve reproduced the corrupted toolbar icon issue. Not certain but I believe there may have been something in a recent Pi OS update to have caused this. Not terribly interested in trying to identify what specific update may have caused it, however, but hopefully a hint to someone else whoās more invested in solving it.
Just so you know, HDMI and VGA are quite different signals with HDMI being digital and VGA being analog. With adapters and such, not only can signals be degraded but also the compute device might not get the serial data from the display to tell it what resolution and frequency to operate at.
Oh Iām very aware of the diffrences between HDMI and VGA any time I do a fresh install. But its what I have.
I also did some more playing around today and I think I figured out the need to launch 1.4 first then 1.6. It appears to be related to the license management window. When I open 1.4 the lic. management window opens. I can close it and open 1.6. The window doesnāt open but but if I try to open in thought the Help menu it crashes. Just food for thought.
So I was thinking of doing this, too, seeing as my 3d printers are all controlled through Octoprint and fabulously so. There is a big difference, though, between a 3d printer and my Falkon 2 (heavily modded), besides the obvious. 1st, I can run a print remotely because everything necessary is on/with the printer, not true with the Falcon. I have to place the wood and run Frame to assure itās positioned correctly. 2nd, well there really is no 2nd since reason 1 is pretty emphatic. The only thing Iād gain from using the Pi is not having to carry the SD card to and fro between my computer and light burn and the engraver to install the file. At this point, thatās not good enough reason to jump through so many hoops, seeing as I have to set things up manually anyway. My two cents on the topic.
My guess is that most people will use this setup because they donāt want to dedicate a full computer to the task of mostly being a USB port serial sender at the machine or they donāt have much room at or around the laser machine.
LightBurn on an rPi handles both of those well and it give the user the ability to slightly modify the design or design placement at the machine.
And for some, the rPi configured with remote display capabilities will also let the remotely watch and control the machine.
And not for everyone.
1 Like
Thanks for everybody contributing to getting LightBurn to run on ARM64!
I was able to build myself a Docker container which runs on a RPI4 containing LightBurn and Kasm VNC server (good performance too!)
I share my lasercutter with my sister, this way the lightburn install does not need to be on her laptop and it works great!
2 Likes
Not sure if anyone is still following this thread or can help me out. I followed all of the instructions including installing RaspiOS from September of 2022 onto my Pi 4. I execute launch.sh, lightburn loading screen pops up, and then it almost immediately quits out.
Can you document specifically what youāve done? Include version information. I see no reason why this wouldnāt work if all steps were followed.
Copy/paste the text output from terminal that you receive.
I currently use RPi4/Lightburn and VNC to laser materials on my Roly Lasermatic 30W laser engraver. A couple of months ago I upgraded the installed LB 1.3.01 to LB 1.7.01. Launching LB 1.7.01 now results in the same issue @mtmgiants reports aboveā¦ it starts loading, momentarily presents the UI, and then crashes out after only a couple of seconds. The previous LB 1.3.01 always loaded and ran properly however.
I am not knowlegeable of the deep technical reason why this happens but have come up with a workaround of sorts. When I installed LB 1.7.01, I saved the old LB 1.3.01 directory structure in ~/.local/share/LightBurn-1.3.01. I then downloaded/executed LightBurn-Linux64-v1.7.01.run, which set up the newer version in its normal ~/.local/share/LightBurn and created the launch icon on the desktop. If I first run LB 1.3.01 (from the command line) and then exit normallyā¦ I can then launch LB 1.7.01 and it will load and run normally. If I reboot the RPi4 and launch LB 1.7.01 ā without first running LB 1.3.01 ā it will crash.
My workaround then is to run and immediately exit the 1.3.01 version first and then launch the later versionā¦ and then simply LEAVE IT RUNNING! Iāve let it run for weeks without rebooting or powering it offā¦ and almost always reliably reconnects through VNC and allows me to run my laser engraver. In the event it loses power, I just run and exit the 1.3.01 version before trying to launch the later version.
Iāve not investigated further because I have a relatively easy workaround. But I do keep a terminal open and can launch from the command lineā¦ and catch a ton of information when I exit or crash LightBurn, usually ending with a segmentation fault. If you canāt figure out whatās going on the information I provided aboveā¦ Iāll try to help and capture the terminal output for you real Linux gurus to peruse.
Hope this helps.
ā David
Please know that Iām 78 years old and forgetful. Iām positive that my observations over the past several months ā and that I shared in my last post ā were accurateā¦ as I remembered them. I canāt duplicate them now, howeverā¦ and even over several reboots in the past few minutes, LB 1.7.01 on my RPi4 seems to be more robust. I canāt get it to crash now.
Iām positive I have consistently seen the same issue as @mtmgiants has seen as recently as a few days agoā¦ and have always been able to clear the issue by first running and exiting the 1.3.01 version of LB and then launching the LB 1.7.01. But something has changed and Iām not sure whatā¦ but itās acting better now.
Sorry.
ā David
I have noticed variations in behavior based on updates to the OS. Itās possible that this is whatās causing some of this variation.
When I have a moment Iāll review the installation against latest OS updates and latest LightBurn version and report back.
Took a look at what was going on with this. I can confirm that it seems that with the latest patches applied to Pi OS and running 1.7.03 that the current ālaunch.shā script and linked libraries do not work.
New OS updates against an older version of LightBurn also doesnāt work. I tested against 1.5.06 which was the last version I actively tested prior and known working.
I can get LightBurn to show up briefly by running the āLightBurnā executable directly without use of ālaunch.shā after setting AutoCheckForUpdates to false in the prefs.ini file located in root .config folder. However, looks like a QT dependency is causing a segmentation fault.
Bottom line right now is that LightBurn on Pi on current versions seems dead in the water.
Iām not particularly motivated to work on this given the future state of LightBurn on Linux. It would be nice to have a working terminal version of LightBurn once the 1.7.x line is retired but itās not clear to me how many people are even actively using this given how this wasnāt even noticed for so long. Worst case people can revert to older revisions of the OS and LightBurn.
2 Likes
Im grateful for your work.
To add to this, I took a crack at it today. Running the latest lightburn with the latest box64 works fine without any Ubuntu imported libraries. For the first run only! Subsequent runs crash on the licence window popup. Nuking the whole .config/Lightburn folder and the directory that contains the licensing stuff also results in failure on subsequent attempts to launch in the same way. md5sum on every file in the directory (and recursive subdirectories) also results in the same. Nuking everything completely will go back to the original state of working on first launch.
I suspect 2 things:
The licensing library assumes (correctly) that hooking syscalls/whatever box64 does to do itās thing is a bypass attempt and SIGINTs or whatever.
Something gets changed post first run (that isnāt file content) that signifies itās not the first run anymore. Perhaps a file attribute.
Will work on it further
Edit: strace manpages are pretty denseā¦
If you look at my previous post you can work around the initial crash by eliminating the update check. It fails on a call to an old SSL library.
However, it will subsequently crash fairly quickly with casual navigation on a QT error.
I donāt recall how you run LightBurn from the emulator but if you run from the .run installer or the 7z installer I think thereās more reliance on Qt libraries being installed in the system. Running from the appimage, using --appimage-extract-and-run brings over lots of LightBurn specific Qt libraries.
I run LightBurn from a Ubuntu 22.04 docker container and in the past only the appimage would run the v1.7.0x versions but I just tried v1.7.04 and it now runs from both appimage and the LightBurn directory after a 7zip extraction. Again, not emulated via box64, running on Kubuntu 18.04 using docker with a system image of ubuntu 22.04
docker.file:
FROM ubuntu:22.04
RUN apt update
RUN echo 'APT::Install-Suggests "0";' >> /etc/apt/apt.conf.d/00-docker
RUN echo 'APT::Install-Recommends "0";' >> /etc/apt/apt.conf.d/00-docker
# Set the locale
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends tzdata
RUN apt install -y libusb-1.0-0
RUN apt install -y libpulse-dev
RUN apt install -y libgl1
RUN apt install -y libxkbcommon-x11-0
RUN apt install -y libxcb-image0
RUN apt install -y libxcb-keysyms1
RUN apt clean
RUN apt install -y libxcb-render-util0
RUN apt install -y libxcb-icccm4
RUN apt install -y libxi6
RUN apt clean
RUN apt install -y libxrender1
RUN apt install -y net-tools
RUN apt install -y iputils-ping
RUN apt install -y libgtk-3-0 fuse locales
RUN apt install -y libqt5gui5
RUN apt install -y libgstreamer1.0-0 libgstreamer1.0-dev gstreamer1.0-libav gstreamer1.0-tools gstreamer1.0-x gstreamer1.0-plugins-base-apps libgstreamer-plugins-base1.0-dev gstreamer1.0-plugins-bad
RUN apt install -y libqt5multimedia5-plugins gstreamer1.0-plugins-bad
RUN apt clean
# Set the locale
RUN sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen && \
locale-gen
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US:en
ENV LC_ALL en_US.UTF-8
RUN echo "$USER:x:1000:1000:Doug LaRue,:/home/$USER:/bin/bash" > /etc/passwd
RUN echo "$USER:x:1000:" >> /etc/group
ENV DISPLAY=:0