After every power on or reconnection, my laser alternates the device node name between ttyUSB0 and ttyUSB1. If Lightburn is running at this point, it loses the connection and won’t work again until I restart Lightburn or disconnect and connect the laser again. Apparently there is some logic in Lightburn that does a bit of auto-detection of what devices are available, but doesn’t always work as expected.
The problem of changing device names in Linux is well known. The standard solution is to use udev-rules to define a constant alias such as /dev/laser, which is always automatically created as SYMLINK on the current ttyUSBX based on USB IDs. Unfortunately, I can’t select this symlink at all in Lightburn. If it were possible, the automatic detection would probably be additionally difficult.
Has anyone found a good way to solve this or are there any plans to optimize Lightburn for this?
I was working on getting grblHAL( grblHAL · GitHub ) running on the JL1 and JL2 diode lasers and experienced the stuck /dev/USBx device issue but I figured it was due to the fact that the JL1 controller had separate power from the micro-controller when other controllers usually have the USB interface reset, and powered with the controller( Ortur for example or at least their original products were this way ).
It might be a bit of a pain, and I’ve not tried it on this “problem” but I recently wrote a bash script to depower and repower a USB device and this might help here. You’ll need to adjust what the script looks for since this was designed for an FTDI serial port controlling a 433MHz wireless transceiver which would ‘get lost’ and needed power bounced.
#!/bin/bash
# look for the FTDI RS232 adapter, find the USB bus number and device number
# look for the bConfigurationValue file which controls the device power
# turn the power off(0) and then turn it back on(1)
#lsusb
#cat /dev/bus/usb/001/011
#dmesg | tail
USB_NUM=`dmesg | tail | grep -m 1 FT232RL | cut -f3 -d " " | cut -f1 -d ":" | cut -f1 -d "-"`
USB_DEV=`dmesg | tail | grep -m 1 FT232RL | cut -f3 -d " " | cut -f1 -d ":" | cut -f2 -d "-"`
echo USB bus and dev = $USB_NUM : $USB_DEV
USB_CONF=`find /sys/bus/usb/devices/usb${USB_NUM}/. -name bConfigurationValue | grep $USB_DEV`
sudo chmod o+w $USB_CONF
echo USB initial power setting = `cat $USB_CONF`
sudo echo 0 > $USB_CONF
echo USB powerdown power setting = 0 #`cat $USB_CONF`
sudo echo 1 > $USB_CONF
echo USB powered up setting = `cat $USB_CONF`
Perhaps a permissions problem? You should be in whatever group /dev/laser has and it should have permissions giving that group read + write access.
Tack a MODE="0660" or, worst case, `MODE=“0777” onto the udev stanza creating that symlink, reboot (*), and see if that improves the situation.
All of which should happen automagically, so something in the setup seems to have fallen off the rails.
(*) There’s a fancy command to update all the USB linkies without a reboot, but I can never keep the syntax straight.
sudo udevadm control --reload-rules
and I've seen this used after the first also:
sudo udevadm trigger
That seems vaguely familiar, but I definitely couldn’t type it from first principles under duress … 
Obligatory XKCD:
The have no problem with a valid tar command … even with my bad memory
jack@Kilo:~$ tar --version
Like the graphic comedy 
I force myself to download some zip and some tgz files but what always gets me is the “to directory” options and sometimes the “full path” options.
Thank you for this idea. The mode of the link was 0777 already. I changed the group with chown -h root:dialout, so it looks as the device node it points to. But in lightburn I still can’t select this link as connection.
Phew! Fixing this definitely requires advice from somebody who knows what they’re doing … 
Try exporting your device configuration and edit the exported file and look for “CommPort” where you can try changing it to “laser” then import that device and see if it sticks.
I have about 4 machines with “QinHeng Electronics HL-340 USB-Serial adapter” in all of them… So I have 4 udev files with the same id/vendor numbers…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.