Lightburn hanging on Linux

LightBurn Software Questions OS Specific
1

I am using the trial version of Lightburn and I am experiencing issues with Lightburn hanging at startup. The issue is virtually identical to that reported by @payala earlier this year – that thread was automatically closed and there seems to be no way of re-opening it.

I am using Ubuntu 18.10 on a laptop with no USB devices connected (not connected to the laser yet). What I am experiencing is that the first time Lightburn is opened after system reboot, it opens fine. On each subsequent invocation, it hangs for just over 60 seconds before showing the main window.

The problem seems to be related to Lightburn trying to access /dev/ttyS0. I have investigated this a little using strace and have discovered the following. On the first invocation the system calls are as follows:

access("/sys/devices/platform/serial8250/uevent", F_OK) = 0
readlinkat(AT_FDCWD, "/sys/devices/platform/serial8250/driver", "../../../bus/platform/drivers/se"..., 99) = 40
openat(AT_FDCWD, "/dev/ttyS0", O_RDWR|O_NOCTTY|O_NONBLOCK|O_CLOEXEC) = -1 EBUSY (Device or resource busy)
openat(AT_FDCWD, "/", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 20
openat(20, "sys", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 21

However, on each subsequent invocation the system calls look like this:

access("/sys/devices/platform/serial8250/uevent", F_OK) = 0
readlinkat(AT_FDCWD, "/sys/devices/platform/serial8250/driver", "../../../bus/platform/drivers/se"..., 99) = 40
openat(AT_FDCWD, "/dev/ttyS0", O_RDWR|O_NOCTTY|O_NONBLOCK|O_CLOEXEC) = 18
ioctl(18, TIOCGSERIAL, 0x7ffc51e15b60)  = 0
close(18)                               = 0
readlinkat(AT_FDCWD, "/sys/devices/platform/serial8250/tty/ttyS0/subsystem", "../../../../../class/tty", 99) = 24

The system hangs for about 30s during the openat() call and then again for another 30s at the close() call, after which Lightburn reports ‘Port open succeeded’ on stdout.

Hopefully this is enough to help you.

Regards,
Chris

2

Did you create a machine device and define it to use /dev/ttyS0 instead of /dev/ttyUSB0 or /dev/ttyACM0?

I recommend you stop LightBurn then delete your configuration and try to manually create a device being sure to use the correct USB device. delete your configuration like this:
rm -rf ~/.config/LightBurn

3

All I have done is install Lightburn and start it up, with my laser connected. It automatically found the laser and was able to use it.

I have done nothing else other than start/shutdown the laptop and Lightburn – I have been using a MacBook with a larger screen to test, but would prefer to use this laptop.

4

then did you open up the device settings and verify it was NOT trying to use /dev/ttyS0?

Also, did you install LightBurn on Linux as per the instructions on the LightBurn site? That includes creating/setting the group privileges( dialout IIRC ).

I’ve been running and using LIghtBurn for a few years on Ubuntu 18.04 but I’ve never used the automatic setup. So while what you did might have worked the first time, I recommend you do learn a little about Linux if you plan on using it. Like using “dmesg” in a terminal window to see what devices show up when you plug/unplug USB cables.

And you can look at the preference file(prefs.ini) stored in the ~/.config/LightBurn directory where you should check that it is NOT using ttyS0 but instead is configured for the correct USB device.

5

It is trying to use /dev/ttyS0, that is the issue. Lightburn correctly detects and uses the laser, which happens to be on /dev/ttyUSB0. However at startup Lightburn still tries to discover other serial ports as explained by @LightBurn in the other thread, regardless of specific device configuration. It is this process that is hanging when trying to access /dev/ttyS0, as I described above.

Thank you for your input. I have been using GNU/Linux operating systems both professionally and domestically for nearly three decades now; I obviously have much left to learn, but I do hope that this meagre experience is sufficient to allow me to use Lightburn successfully.

Regards,
Chris

6

@space.dandy What model of laptop are you running and is /dev/ttyS0 a device that you actually are using for anything?
Typically that’s a vestigial 9-pin serial port device that may not even actually exist as real hardware on your machine.

I can’t tell you for sure why it hangs during openat() but I’d say it’s pretty clear the reason it doesn’t hang when you first run it is that /dev/ttyS0 is busy the first time LightBurn tries. All we are doing internally is scanning for serial ports and querying their names - but we don’t try to connect to them unless that device is actually selected or during the automatic device discovery wizard (We connect to see if it responds like a controller would). But once you’ve selected /dev/ttyUSB0 as the device to use, LightBurn will not attempt to actually connect to /dev/ttyS0 unless you manually select that device.
My point here is that it would seem that it’s hanging when we are trying to discover the device/port info - which is something we can’t disable because we have to get that information so that we can display it to the user. Why it’s hanging, however, is outside the control of LightBurn - getting the device port info should be a pretty standard thing and we just call out to a standard Qt function to get it for us.

If you can confirm that /dev/ttyS0 is not an actual device being used in your system, my recommendation would be to change it’s owner and group to root or to set it’s permissions to something weird like 222 (write only) so that when LightBurn tries to read from the port it is immediately denied.

7

I’m using a fairly recent Thinkpad X270. /dev/ttyS0 isn’t terminated as a user port either on the laptop or docking station but it is detected as real hardware, so perhaps it is used internally somewhere.

Correct. I have tried duplicating this with a bit of C code, but I have so far been unable to replicate Lightburn’s behaviour. My code simply open()'s then close()'s /dev/ttyS0; it always receives a valid file descriptor and never hangs, unless Lightburn has been previously run. Lightburn always gets EBUSY the first time it is run, then subsequent runs hang and eventually return a valid file descriptor.

Lightburn is traversing /sys prior to opening /dev/ttyS0, so I wonder if there is some strange interaction going on there.

That’s not actually correct, depending on what you mean by ‘connect’. Lightburn, whether intentional or not, always scans the system for serial devices at startup. Each device that it thinks may be a serial device is opened, it then calls ioctl(TIOCGSERIAL) to get the serial characteristics, then it is closed. It does this regardless of whether there is a device configured or not. Lightburn does not attempt to read or write to the serial device, which perhaps is what you mean by ‘connect’?

Understood. But it would help if Lightburn didn’t try to scan for serial ports at all until discovery is requested. That would at least mitigate the issue.

Perhaps it is an underlying issue with Qt. Are you willing to share the snippet of code that does the serial port discovery?

8

Yes, that’s what I meant. Internally we are asking Qt for info on the serial device so it’s Qt that’s doing the open. We do not however try to write/read the device.

The only way we could do that is to provide a setting that tells it to just remember the path and only attempt to use that in the future. You would no longer be able to select a device from the drop down. I admit, this would make sense to Linux users but not really for windows. I’ll look at how hard that would be to do just for Linux - we could maybe make it so that it doesn’t try to do device discovery until you click on the drop down, but it would just hang at that point instead.

It’s just using QSerialPortInfo::availablePorts()
And then getting device info from the QSerialPortInfo objects that are returned.
And yeah, it would not surprise me if it’s an issue with Qt. We are building currently on Ubuntu 16.04 with a similarly old version of Qt - we are already planning on having the discussion of if we can move to newer versions and what that will mean for our users (most likely dropping support for older versions of Linux).

9

What version of Qt are you using? I’ve just tried building a test app using QSerialPortInfo::availablePorts under Ubuntu 18.10 with Qt 5.11.1 and I can’t reproduce the problem.

10

It’s currently built for Linux with 5.10.1

11

I’ve just installed 5.10.1 on my Ubuntu 18.10 machine and I still can’t duplicate the issue. I’ll try spinning up a 16.04 VM and see if that changes things.

I’m happy to continue this privately if you’d prefer, to avoid spamming the forums.

12

Ok, I’ve just tried building the test app with Ubuntu 16.04 and Qt 5.10.1 and I still can’t replicate the issue.

13

Can you go and grab the latest beta release from here?
https://drive.google.com/drive/folders/1M7eD8N8tpT8gNC-EyOmc9I9A5cSBBkYc
Download the .7z version for linux and extract it, then at the terminal cd to the directory it creates and run:
./LightBurn -d

The -d will run it with debugging enabled from the start (it was just added, hence the beta version).
What you will be looking for is a section of output that says: Enumerating ports:
And the listings starting with Port: below that.
Ideally watch this as it’s happening and see if you can notice if the delay is happening in that section specifically… for example if it shows Enumerating ports: and then there’s a delay before anything is shown. Or if the delay is between port listings. Or even if between those Port: sections.

Better yet, capture a video of it happening and share it with us. Since I can’t locally replicate the issue that would be the next best thing to narrow down where exactly in the code the hangup is occurring.

14

I have a laptop with a real RS232 serial port on it if that device is what is causing this and I can try running 18.10 and LightBurn 0.9.24 if it’s helpful.

I only run Linux(Kubuntu 18.04) and run LightBurn on 2 different machines and have tested it in a few different versions of Ubuntu( usually Lubuntu versions ).

15

I’ve attached the timestamped output. The two delays are occurring immediately after ‘Enumerating ports:’ and ‘Name: “ttyS0”’.

The first few lines of output show ‘Splash created’ and ‘Splash shown’, but this is not happening fully – there is a translucent outline of a splash screen, but that’s all.

output.txt (2.7 KB)

16

Interesting, thank you @space.dandy
Out of curiosity, does this still happen if you have a laser connected?
You might have to connect the laser and connect to it once first for it to remember which port to use.
Still digging into this… will let you know as I find more.

17

Hmm, no actually it doesn’t:

Jun 03 14:34:43 Any ID allowed
Jun 03 14:34:43 -- candidate port PID 29987 VID 6790
Jun 03 14:34:43     mfr:  "1a86"
Jun 03 14:34:43     prod: "USB Serial"
Jun 03 14:34:43     name: "ttyUSB0"
Jun 03 14:34:43 Found port: PID 29987 VID 6790
Jun 03 14:34:43 Manufacturer: "1a86"
Jun 03 14:34:43 Product: "USB Serial"
Jun 03 14:34:43 Name: "ttyUSB0"
Jun 03 14:34:43 Port open succeeded
Jun 03 14:34:43 "starting"  busy:  false  state:  0
Jun 03 14:34:43 EV: 1001 took 10 uS
Jun 03 14:34:43 EV: 1001 took 5 uS
Jun 03 14:34:43 EV: 1018 took 9 uS
Jun 03 14:34:43 EV: 1015 took 535 uS
Jun 03 14:34:43 Enumerating ports:
Jun 03 14:34:43 Port: "ttyUSB0"
Jun 03 14:34:43       Valid Candidate:  true
Jun 03 14:34:43       PID: 29987 VID: 6790
Jun 03 14:34:43       Manufacturer: "1a86"
Jun 03 14:34:43       Description: "USB Serial"
Jun 03 14:34:43       System Loc: "/dev/ttyUSB0"
Jun 03 14:34:43       Serial: ""
Jun 03 14:34:43
Jun 03 14:34:43 Port: "ttyS0"
Jun 03 14:34:43       Valid Candidate:  true
Jun 03 14:34:43       PID: 0 VID: 0
Jun 03 14:34:43       Manufacturer: ""
Jun 03 14:34:43       Description: ""
Jun 03 14:34:43       System Loc: "/dev/ttyS0"
Jun 03 14:34:43       Serial: ""
Jun 03 14:34:43
Jun 03 14:34:43   I: "o\x1E\x00""A\x94QP\xD6X\x01\xE1\x84\x82X\x84\xE2@\x90\xD3KQ@\xC2\xA2`\xFE\xB8\x8D\xFF"
Jun 03 14:34:43 Any ID allowed
Jun 03 14:34:43 Looking for port: "ttyUSB0"
Jun 03 14:34:43 -- candidate port PID 29987 VID 6790
Jun 03 14:34:43     mfr:  "1a86"
Jun 03 14:34:43     prod: "USB Serial"
Jun 03 14:34:43     name: "ttyUSB0"
Jun 03 14:34:43  - found matching port name
Jun 03 14:34:43 Found port: PID 29987 VID 6790
Jun 03 14:34:43 Manufacturer: "1a86"
Jun 03 14:34:43 Product: "USB Serial"
Jun 03 14:34:43 Name: "ttyUSB0"
Jun 03 14:34:43 Port open succeeded

If I then disconnect the laser and try again, the first time it starts fine but tries to use ttyS0 sending “G0\n” repeatedly. The second time it hangs again.

18

Ok, that’s what I figured. So digging in more, I was wrong and we do actually try to connect - it’s just abstracted away so I missed it. The thing is that we will always try to connect to the previously used device path if it exists, but if not we try to connect to any serial devices found. While not really the case with Linux, a big reason for this is that on Windows the port number may change. Though I’ve seen it change on Linux too, it’s just more rare - you’d have to have more than 1 serial device connected and have changed which physical USB port you used.

Granted, I’m still unsure why it hangs when trying to connect to that specific port on your machine so I don’t have a direct solution for you. I’ve discussed with the dev team and automatically trying to connect really is the desired behavior - we just have never had the issue of trying to connect to non-laser serial devices causing it hang so that it’s never been an issue.

We’ve discussed simply excluding ttyS0 from being seen as a valid serial port but I want to be 1000% sure it’s impossible that could ever be used for a laser. Probably so unless someone did something weird like symlinking ttyS0 to ttyUSB0. There’s also talk of having a user editable exclusion list - but we’ve haven’t decided yet.

For now I think your only option is to figure out if that ttyS0 device is actually real and if it’s used for anything. If not, change it’s owner to root and you should be good.
Once I have some sort of fix I’ll get you a build so that you can test it out.

19

As far as I know, ttyS* devices are exclusively ‘real’, so it might be a useful compromise to simply ask the question as part of the initial setup: ‘does your machine have a 9-pin serial port’ and exclude based on that answer.

Thanks.

20

But your machine doesn’t have a 9-pin serial port, right? So that wouldn’t have done anything in your case.