Just speculating but I would have thought it was the iPad(iPadOS) which also ran on Apple ARM chips which really got them thinking of scaling their custom ARM SOC upto desktop capabilities.
The Mac ARM chips are fast and powerful and to run x86 MacOS apps they have a virtual machine tool called Rosetta which allows x86 apps to run on these new Apple ARM chips. So yes, LightBurn does already run on Apple ARM PCs but they do it through emulation so LightBurn devs don’t yet have to change anything.
When I was switching from the EE track to CS track in the late '80s I was working as a electronics tech and was asked to help the local ME who was redesigning the manufacturing floor and adding some nice new equipment like surface mount solder station which was relatively new back then. We got to know each other a bit and one day he says to me that I should switch and get an ME degree.
When I asked why he hold me it was because I could get my degree, travel the world for 3 or more years and still easily get hired as an ME because the laws of Physics won’t have changed. I told him I was switching to Computer Science because it changes so much. Following hardware and software takes at least 2 hours / day scanning news sites and reading up on how the new stuff works. Never was great at any one thing and it’s getting more difficult to keep up let along remember stuff from 10, 20, 30+ years ago.
But have been a UNIX fan since using it in the '80s and so happy LightBurn supports Linux even if it’s only on x86. That hardware is cheap these days.
Yes, this is really feasable. But the problem is Lightburn doesn’t support any kind of integration with octoprint (or other software).
When I use octoprint with prusaslicer, I have a single button to send gcode to octoprint.
If i want to use it with LB I have to save gcode, the open it in octoprint. It works, but a little annoying.
Instead to have LB running on RaspberryPI I would prefere to have some API or IPC from LB to others. But is just my 2c.
I used usbIP to do remote control with a Raspberry Pi running the usbIP at the laser and since my desktop is also Linux, it’s running there too. I think there are Mac and Windows options like this.
And I was engraving cork outside with a diode laser with a fan on it. Running a high power laser without in-person monitoring is not recommended.
I found a USB client server that’s free for one connection, the server runs on any version of raspberry pi from 0 to 4B it’s easy to install and start.
In light burn it shows up as just another USB port. A one time sever license is $49 and gives you all the options, it’s called VirtualHereUniversal
I’ve made some effort to update to latest current LightBurn and to provide for latest Ubuntu 2020.04.6 libraries.
This latest set of changes come with several quality of life improvements and brings this to what I would consider a perfectly usable state. Try this if it’s of any interest to you.
Basically, everything I’ve tried works with the major exception of the camera. However, the camera is detected and trying to use the camera no longer crashes LightBurn.
I believe this is due to difference in symbols provided by some native libraries in Raspberry Pi OS vs Ubuntu but not certain. Would appreciate if anyone can track this down.
Summary of changes:
Updated to LightBurn 1.4.03
Updated to Ubuntu 2020.04.6 for x64 libraries
Online Activation now works correctly; no need for offline activation
Software Update directly in LightBurn should now work
What doesn’t work:
Camera fails to deliver a picture. I’ve included some of the expected gstreamer plugins but still not working
@berainlb Having the same issue as @bhimio … Working with a RPi 4 running Debian GNU/Linux 11 (bullseye), kernel version 5.15.84-v8+. I have uncompressed the two 7z library archives to the LightBurn folder… all libs except libzstd.so.1 seem to load just fine. Here is the output:
Dynarec for ARM64, with extension: ASIMD CRC32 PageSize:4096 Running on Cortex-A72 with 4 Cores
Params database has 30 entries
Box64 with Dynarec v0.2.5 12c40a5b built on Oct 25 2023 06:25:21
BOX64: Prefer Emulated libs
Counted 25 Env var
BOX64 LIB PATH: /home/jwebster/Downloads/LightBurn/lib_amd64/lib/x86_64-linux-gnu/:/home/jwebster/Downloads/LightBurn/lib_amd64/usr/lib/x86_64-linux-gnu/:/home/jwebster/Downloads/LightBurn/lib_amd64/usr/lib/x86_64-linux-gnu/pulseaudio/:/home/jwebster/Downloads/LightBurn/lib_amd64/usr/lib/x86_64-linux-gnu/gstreamer-1.0/:/lib/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/
BOX64 BIN PATH: ./:bin/:/usr/local/bin/:/usr/bin/:/bin/:/usr/games/
Looking for /home/jwebster/Downloads/LightBurn/LightBurn
Rename process to "LightBurn"
Using native(wrapped) libusb-1.0.so.0
Error loading needed lib libzstd.so.1
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5MultimediaWidgets.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5PrintSupport.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Widgets.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Multimedia.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Gui.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5SerialPort.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Network.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Xml.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Core.so.5
Using native(wrapped) libpthread.so.0
Using emulated /lib/x86_64-linux-gnu/libstdc++.so.6
Using native(wrapped) libm.so.6
Using emulated /lib/x86_64-linux-gnu/libgcc_s.so.1
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libdl.so.2
Using native(wrapped) libutil.so.1
Using native(wrapped) librt.so.1
Error loading one of needed lib
Error: loading needed libs in elf /home/jwebster/Downloads/LightBurn/LightBurn
Since the script reports using emulated libs in /home/jwebster/Downloads/LightBurn/lib/, I also tried copying libzstd.so.1 to that folder (thinking it may be a PATH/environment issue)… same result. To ensure the environment variables were getting set properly, I added an export comand to the launch script. Here are the relevant variables printed:
I’m very keen to get this working with BOX64, so I appreciate all of the effort you have put into this to get it working, and hope you have a few suggestions.
I haven’t attempted this with anything other than Raspberry Pi OS and a difficult attempt with Ubuntu that was impractical due to the Raspberry Pi 3 I’m running.
Can you first try this with Pi OS “September 22nd 2022” to see if things work correctly at all? I’ve done this in a bubble and have had no independent verifications that this works so would like to confirm first. I suspect this should work fine with a newer edition but I haven’t tested that way.
The balance of native and emulated libraries makes this whole affair a bit tricky. The emulated libraries I’ve controlled by bundling those libraries from Ubuntu 2020.04 but the native libraries being different can create different symbol dependencies that need to be reconciled.
@berainlb OK, completely fresh install of raspios_arm64-2022-09-26… and followed your 12 Nov post “Installation and Usage:” list verbatim. Fortunately (or, unfortunately, depending on perspective), it didn’t work. Same exact error running a completely different raspi OS version. I say “fortunately” because, if it worked on your system, there is likely a small tweak to make this work on many systems. Screenshot of all of the output below:
I think I’ve resolved the problem. When I initially uploaded the library archives I had to repackage the libraries to split them into 2 files to get under the maximum file size limit on the forum. When I did that it appears I broke the symbolic links.
I’ve updated the post with corrected archives. Please test and confirm whether or not it’s working correctly.
@berainlb Well, I think we are closer! No more libzstd.so.1 error… but several other libraries seem to be missing. See output below… and note: though you updated Post 8 to include a .tgz archive, I think it is only .tar. Also, it extracts without relative paths (in other words, all the libraries decompress to the folder the archive is in, rather than with the …/libs64/… pathing you had in the original archives.). I don’t know that it is a problem per se, but it is a difference. It may be that you just need to include the libraries missing as noted from the output:
Dynarec for ARM64, with extension: ASIMD CRC32 PageSize:4096 Running on Cortex-A72 with 4 Cores
Params database has 30 entries
Box64 with Dynarec v0.2.5 12c40a5b built on Oct 25 2023 06:25:21
Counted 27 Env var
BOX64 LIB PATH: ./:lib/:lib64/:x86_64/:bin64/:libs64/:/lib/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/
BOX64 BIN PATH: ./:bin/:/usr/local/sbin/:/usr/local/bin/:/usr/sbin/:/usr/bin/:/sbin/:/bin/:/usr/local/games/:/usr/games/
Looking for ./LightBurn
Rename process to "LightBurn"
Using native(wrapped) libusb-1.0.so.0
Using emulated libzstd.so.1
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5MultimediaWidgets.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5PrintSupport.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Widgets.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Multimedia.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Gui.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5SerialPort.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Network.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Xml.so.5
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5Core.so.5
Using native(wrapped) libpthread.so.0
Using emulated /lib/x86_64-linux-gnu/libstdc++.so.6
Using native(wrapped) libm.so.6
Using emulated /lib/x86_64-linux-gnu/libgcc_s.so.1
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libdl.so.2
Using native(wrapped) libutil.so.1
Using native(wrapped) librt.so.1
Using emulated /home/jwebster/Downloads/LightBurn/lib/libQt5OpenGL.so.5
Using native(wrapped) libGL.so.1
Using emulated libpulse-mainloop-glib.so.0
Using native(wrapped) libpulse.so.0
Using native(wrapped) libglib-2.0.so.0
Using native(wrapped) libz.so.1
Using native(wrapped) libgssapi_krb5.so.2
Using emulated /home/jwebster/Downloads/LightBurn/lib/libicui18n.so.56
Using emulated /home/jwebster/Downloads/LightBurn/lib/libicuuc.so.56
Using emulated /home/jwebster/Downloads/LightBurn/lib/libicudata.so.56
Using native(wrapped) libgthread-2.0.so.0
Error loading needed lib libpulsecommon-13.99.so
Error loading one of needed lib
Error initializing needed lib libpulse-mainloop-glib.so.0
Error loading one of needed lib
Error initializing needed lib libQt5Multimedia.so.5
Error: Symbol pa_log_level_meta not found, cannot apply R_X86_64_JUMP_SLOT @0x104de4fb8 (0x1120) in libpulse-mainloop-glib.so.0
Error: relocating Plt symbols in elf libpulse-mainloop-glib.so.0
Error initializing needed lib libpulse-mainloop-glib.so.0
Error loading one of needed lib
Error initializing needed lib libQt5MultimediaWidgets.so.5
Error loading one of needed lib
Error: loading needed libs in elf /home/jwebster/Downloads/LightBurn/LightBurn
— UPDATE, and apologies for this addendum, LB forum won’t let me post more than 3 replies at the moment — @berainlb Update: I had deleted the original ./LightBurn/ folder to try your latest lib archive – which didn’t work as noted above because I only extracted the libs in Post 8 to the root of the ./LightBurn/ folder. I extracted the other two lib archives from the original posts (e.g., 1of2 and 2of2, including the relative paths)… and IT WORKED. LB is now running (at least on the Sep 22 2022 version of RaspiOS). I will now try to go back to my original distro install and see if it works. Will report back shortly…
(You may just have to clean up the lib archives and edit the posts so others can follow along.)