I think I’m Linux-Blind…
I’m fairly certain that I’ve seen some strange “sudo” permissions required for some of the USB communication settings in Linux. I’m glad you had that one up your sleeve.
Don’t remember what Chinese product I was using, maybe one of the $80 machines with a 32bit control board, I got from Amazon.
1 Like
That was a great couple of months of heavy posts.
I have had to be away at a space weather conference since my last post. Very late before I left I was able to etch a modest scratch into a piece of steel by running Lightburn as root from the command line.
I feel that I understand better what what is going on. It appears to be written using QT5 using that programming environment’s ‘slots’ API, something that I have rarely used.
So my problems probably comedown to a problem of permissions needed to open the ‘slots’ in question, something that I may have missed setting up in one or more of my installation attempts.
Also, the timeouts seem to be a bit short when it attempts to detect an appropriate device. This was giving me errors even it succeeded in finding my machine.
I will be investigating these matters and reporting what I find - no matter how foolish it makes me look.
Dave
My time to work on this is spotty, but I believe that I am working toward a solution.
All indications at this juncture seem to imply that though all my test user accounts have been given both dialout and tty group membership, the actual USB interface used by this controller does not recognize these groups as conveying good or sufficient permission to connect.
I have created a standalone Ubuntu 22.04 system with no other purpose than running LightBurn and followed every installation instruction that I have found or have had suggested. I find the Nanny-isms of this distro repugnant, but it is the one most often cited as ‘supported’.
At this point it seems to me that what is missing is a UDEV rule or rules that give permission to these groups to access this port.
Though I am a long time Linux user and developer, I rarely have occasion to grub around in the this corner of the belly of the beast. But grub I must, I guess.
Either there is no setup of these permissions in the distribution packages, or something has caused me to deviate from the path(s) that the maintainers anticipated I would use.
If anyone could suggest where these presumed presumed missing or dead UDEV rules might be found, I would appreciate the help.
I have solved this problem and I see why this causes Linux users lots of grief. Perhaps not all Linux users, but certainly most of them and likely all who are using recent clean installs of Mint, Ubuntu, and Debian .
The solution is quite simple, but I do not see it clearly stated. It is not sufficient to have the LightBurn user be a member of the plugdev, tty, or dialout groups. That might have worked at some time in the past, and if it did and you just did upgrades in place certain permissions may have been carried forward - I don’t know.
But for a fresh install of Ubuntu 22.04 LTS you must do something else. You MUST have a udev rule in place that gives access to the specific device seen by lsusb. In my case, and probably many other users who have lasers based on the EZCad2 driver boards, the udev rule must give access to the Device:
Bus 003 Device 004: ID 9588:9899 BJJCZ USBLMCV4.
In my case and probably many others, placing a text file in the folder /etc/udev/rules.d/ that contains these lines (after rebooting) does the trick:
# Lightburn Laser access
# This file should be installed to /etc/udev/rules.d so that you can access the LightBurn USB hardware without being root
#
# type this at the command prompt: sudo cp 98-LightBurn.rules /etc/udev/rules.d
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="9588", ATTR{idProduct}=="9899", MODE="0666"
I named this file 99-LightBurn.rules.
As the folder /etc/udev/rules.d is owned by the root yser, you have to use sudo to create it or copy it there.
Without this, only a user running with root permissions may open the laser’s USB device. It doesn’t matter what other permission the user has.
I don’t see why this is not clearly documented somewhere or these permissions are not incorporated in the AppImage or other installation packages. It could be so easy…
Dave
I’ve never had a file in udev, until recently when I was trying to chase down where/how it connected.
Never never have found where it gets mounted, it doesn’t appear to be in /dev directory.
Jack,
Yes, it goes in /etc/udev/rules.d/
There is no entry in /dev unless it is buried deeply.
The file should be given a name starting with a number - like ‘99-Lightburn.rules’.
Systemd uses the initial number to decide which rule files to run first, sometimes there is a conflict. But on my clean machine there were no other rules files to worry about.
These files are loaded at startup by systemd - the modern system initializer. Many Linux users live out perfectly happy lives without ever knowing a thing about it. But it really controls everything.
There is a command that can reload these files without needing to reboot - something like ‘sudo systemctl reload devices’ (but don’t quote me).
Once the file is in the right place, it will just work and you don’t have to think about it again on that system.
I figured this out a couple of weeks ago, but haven’t had time to post it
Thanks for all your help!
I used it to try and specify a /dev file name and it never would.
There was no file for it until I tried to get it to mount in /dev
Probably why it wasn’t included in any documentation for installation… I’d think if it was required, they would mention it.