xTool GRBL - ChromeOS - Linux - Lightburn USB Connection Issues

Can you take a screenshot of the Console window in LightBurn? It should be on the top right pane of the main screen. If the tab is not available make sure Console is enabled in Window menu.

Can you try connecting to the laser from Terminal?

sudo screen /dev/ttyUSB0 230400

Once connected, try issuing some commands:

$I
?

Use exit command to get out of screen command.

For the multiple “device disconnected” messages. Do those correlate to times you’ve reconnected the machine or recycled power?

Screenshot 2022-09-23 4.02.46 PM

image

I suspect they are connects and disconnects on my part. They dump at the same time, and after closing lightburn and terminal, re-issuing the command, the same log returns.

I have been able to get info off /dev/ttyUSB0 before. Not sure why it’s not showing currently.

Apparently the screen command doesn’t ship with your installation.

Try this. Can you cycle through the various baud rates in Edit->Device Settings? Just go slower one at a time and try connecting. You may need to right-click on the Devices button in Laser window to force a reconnect. Make sure that the port is still selected.

I do need to reattach the USB connection after each disconnect
Screenshot 2022-09-23 4.12.59 PM

I did notice this message when clicking device:
Screenshot 2022-09-23 4.16.32 PM

Tried a couple common baud rates before, but I’ll cycle through and let you know what I find.

Thanks again for working through this with me, I’m pretty lost.

Multiple times you stated this so I think you don’t know what that is really doing and may be doing it incorrectly. What’s going on is that Linux/UNIX has users of the system and each user gets a User ID to use the machine. Even if you are the only user on the machine you should have a userID.

Each user, userID, gets rights to access only certain parts of the operating system so when a user wants to use a device, like /dev/ttyUSB0, then the user has to be added to the group which is associated with the device. Often it is the dialout group.

So what we’d want to hear is that you added the userID to the dialout and tty groups.

If you don’t add the correct userID to the correct group it will not work. I don’t know if your Chromebook gives you a command prompt but if it does, try typing “whoami” and it should show you who the user of that console window is. IIRC you would then use “sudo adduser $USER dialout” to add the userID stored in $USER variable(same as ‘whoami’ showed) to the dialout group.

You would also want to see what the /dev/ttyUSB0 device is setup as. Use this to see the long list:
ls -l /dev/ttyUSB0

You should see something like: crw-rw---- 1 root dialout 4, 64 Sep 20 20:27 /dev/ttyUSB0
Where you can see it shows “root dialout” which means the device is part of the dialout group and you have correctly added your user to the correct group.

No luck. Tried going down from 234000, switching to my other USB port, then going back up.

May or may not be noteworthy, but every time I switch USB ports the drop down cycles up 1… ttyUSB0 >> USB1 >> USB2 all the way up to 7 then it drops back to 0. Maybe I’m playing ring around the rosy with the ports connections?

While potentially annoying this shouldn’t be a fundamental problem assuming that permissions are addressed.

Ok. This is weird. Just for records sake, I did not run any additional commands to tty or dialout to $USER or any other var.

I do understand permissions, and why Linux is more secure through walling root, and whatnot. I’m not sure if I literally granted userID or my b4sommer user originally.

After power cycling the laptop, and connecting linux automatically through lightburn app, I’m now seeing the following and have laser movement!

Screenshot 2022-09-23 4.46.25 PM

I honestly am still not sure what the heck I’m doing, or not doing, wrong here. I did disconnect the USB and reconnect to verify it was still on USB0. Will let you know if the situation changes… after restart?

1 Like

Haha. There may be something that required the reboot for it to take effect properly. But looks like you’re in business.

It’s back to squat. I’m sure I’m being dumb here. I’m a product engineer with a programming background and my close friends tell me so regularly… CRIES (very) sadly

To be fair, from what I’ve seen xTool controllers tend to be temperamental when it comes to connectivity.

Do you recall what the USB port number was when it did work?

Try listing the device as @DougL suggested:

ls -l /dev/*USB*

Screenshot 2022-09-23 5.13.10 PM

I’m scared… and feeling a bit vulnerable…
Screenshot 2022-09-23 5.14.08 PM

Screenshot 2022-09-23 5.14.36 PM

@Democreous yes, once you add a user to a group you have to log out and then back in… or reboot.

You were messing with baud rates and that is likely why you got garbage data for a bit.

I would unplug the laser from the Chromebook and reboot the Chromebook. I would also power off the laser, wait 1 minute, power it back on and wait one minute for it to boot. THEN I would plug in the laser USB cable and then I would start LightBurn. It sure as heck should be on /dev/ttyUSB0 and if it’s ‘root root’ there might be some work in /dev/udev/rules work needed.

No go on the restart order. I haven’t been able to re-establish a connection either after experimenting with some different startup orders and usb ports. ls returns properly:
Screenshot 2022-09-24 4.25.11 PM

I suspect you’re correct about udev rules. I did find this post which has a similar problem and a resolution: No connection to Lightburn after upgrading to Ubuntu 22.04

Using their process as a guide:

Running lsusb returns:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 011: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Running dmesg, this popped out to me:

[ 4.362301] virtiofs virtio12: virtio_fs_setup_dax: No cache capability
[ 4.573319] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 4.582680] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 4.611591] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
[ 4.677071] serial8250: ttyS2 at I/O 0x3e8 (irq = 4, base_baud = 115200) is a 16550A
[ 4.725882] serial8250: ttyS3 at I/O 0x2e8 (irq = 3, base_baud = 115200) is a 16550A
[ 4.802470] printk: console [hvc0] enabled
[ 4.811924] printk: bootconsole [uart8250] disabled

[ 8.494697] maitred: failed to enable LRO for eth0: Operation not supported
[ 8.504882] maitred: Failed to enable LRO: failed to enable LRO for eth0: Operation not supported
[ 8.519565] maitred: Set default IPv4 gateway for interface eth0 to 100.115.92.25
[ 8.538976] maitred: Received request to update VM resolv.conf
[ 8.555627] maitred: Received mount request
[ 8.681150] EXT4-fs (vda): mounted filesystem without journal. Opts:
[ 8.687314] maitred: Mounted “/dev/vda” on “/opt/google/cros-containers”
[ 8.715828] maitred: Received request to mount 9P file system
[ 8.734062] maitred: Mounted 9P file system on /mnt/shared
[ 8.755971] maitred: Received request to get kernel version information.
[ 8.763217] maitred: Received StartTermina request
[ 9.013810] BTRFS: device fsid 8d5067a3-b304-4924-9932-2619870e44ce devid 1 transid 608 /dev/vdb scanned by grpcpp_sync_ser (105)
[ 9.032966] BTRFS info (device vdb): flagging fs with big metadata feature
[ 9.038468] BTRFS info (device vdb): turning on sync discard
[ 9.044823] BTRFS info (device vdb): disk space caching is enabled
[ 9.062032] BTRFS info (device vdb): has skinny extents
[ 9.137195] maitred: This system has transitioned to LXD 4.0.x
[ 10.335664] usb 1-1: new full-speed USB device number 2 using xhci_hcd
[ 11.071886] ch341 1-1:1.0: ch341-uart converter detected
[ 11.148601] usb 1-1: ch341-uart converter now attached to ttyUSB0
[ 20.324161] lxdbr0: port 1(veth00244447) entered blocking state
[ 20.336096] lxdbr0: port 1(veth00244447) entered disabled state
[ 20.349395] device veth00244447 entered promiscuous mode
[ 21.681336] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation
[ 21.728227] physaUDOml: renamed from vethdce4a649
[ 21.740893] eth0: renamed from physaUDOml
[ 21.758706] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 21.776307] lxdbr0: port 1(veth00244447) entered blocking state
[ 21.777632] lxdbr0: port 1(veth00244447) entered forwarding state
[ 21.782183] IPv6: ADDRCONF(NETDEV_CHANGE): lxdbr0: link becomes ready
[ 22.660033] new mount options do not match the existing superblock, will be ignored
[ 23.353332] cgroup: systemd (250) created nested cgroup for controller “memory” which has incomplete hierarchy support. Nested cgroups may change behavior in the future.
[ 23.375348] cgroup: “memory” requires setting use_hierarchy to 1 on the root

Did not see anything hijacking my port, but wasn’t entirely sure what to be looking for.

I was also unable to get grep -riIn “1a86:7523” /usr/lib/udev/rules.d/* to return anything. I’m unsure how to go about editing rules from here.

for now, bypass all rules and security and run this on the /dev/ttyUSB0 port or which ever one is attached to your laser USB device:

sudo chmod 777 /dev/ttyUSB0

What it does is set all permission groups to Read, Write, eXecute so any and every application and user can access the port. If that works then you will need to create a custom rules file specifically for your device so that when it is plugged in, the OS creates the device with proper permissions.

if you want to see what’s going on then run this before you do that command and then after that command is run:
ls -l /dev/ttyUSB0

That command is looking for the exact string, “1a86:7523” in any files in the /etc/udev/rules.d/ directory. If you did not create a rule there using that string then there is no expectation there would be one so when you run that command I would it expect it to return nothing.

Are you getting some output saying the /dev/ttyUSB0 device is in use by another device?

First, big thanks to berainlb and DougL. I’ve certainly learned a couple new things about USB and Linux.

PROBLEM: Connection to LightBurn could not be established through USB

PROBLEM OBSERVATIONS:
Screenshot 2022-09-23 3.18.31 PM
Screenshot 2022-09-23 4.16.32 PM
Laser will also show as Disconnected instead of Ready:
image

SOLUTION: Here is a 14 minute video I found about flipping a firmware switch that best emphasizes my reaction: xTool D1 Laser - Manual Firmware Update and 'The Switch'. - YouTube
Hint: Flip the switch toward the reset button, not the rotary tool port.

I stumbled across this solution accidentally after reading the below from xtool and switching on and off the laser. At some point, I happenstance flipped the firmware switch, restarted, and voila! A couple iterations later, and I had a repeatable, working laser!

Basically, the fire-up order doesn’t matter. Connect the USB cord. Hit Connect to Linux when you turn on the laser or plug in the cord after the laser is turned on. Start up LightBurn before or after that last step, doesn’t matter. Select your USB connection next to device inside LightBurn. And…You’re good to go.

I did confirm I was not totally off my rocker, and the laser will work with the switch in either position on Windows. Not the case for Linux however. IMO, xTool should put a simple label on this switch, as there is no indication of whether it is in the open or locked position unless you have it memorized. I’m adding a label as we speak.

Hopefully this helps anyone in the future from having to go through what I just went through.

Cheers!

Yay. Glad you got it. I think it working the one time in Linux probably didn’t really help in the troubleshooting.

By the way, you’re essentially correct about startup order not making a difference. While you’re right in that there’s nothing that can’t be overcome about the start order, be aware that LightBurn attempts to “auto detect” or retain the last used setting. If LightBurn is started without the same conditions as when it was shutdown it will “forget” your current port setting and need to be selected manually even after connection of the device. This trips up people so just be aware.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.