We don’t officially support Ubuntu 20 - We build and test on 16 and 18. That said, very few of the crashes we’ve had have been Linux specific, so it could be something about the laser itself.
Try this:
Run LightBurn
Go to Help > Enable debug logging
Connect to the laser and do something that has made it crash in the past
If you get it to crash, see if anything is emitted to the console, or ends up in the ‘LightBurnLog.txt’ file you’ll find in the Documents folder.
Any time you do this, delete any existing log file before you start, as the existing log is constantly appended to, and will grow forever if you don’t clean it out once in a while.
yes, I’ve followed that and my user is in the dialout group. Actually, lightburn has connected with the laser in a couple of occasions and I was able to cut.
BTW, I find it interesting that once it has crashed, Lightburn is not able to start again even with the laser disconnected from the PC. I will reboot again and try to get another log.
OK, so the lines with “O:” are the output that Lightburn is sending to the laser, right? I can connect to the laser with pronterface, so if you want me to send some commands manually, I can do it.
I’ve tested to connect directly with a serial terminal to the laser. I can send commands and it responds correctly. I send ‘\n’ and the response is ‘ok’, I send ‘G28’ and it homes, same with G1 moves. This at least confirms the serial output working correctly.
I did a bit more research, I’m sniffing usb with wireshark. I can confirm that Lightburn doesn’t get to send anything to the serial port, and it crashes.
After crashing, I connect with a terminal to the laser and just type ‘\n’ (0x0d). I can see my output:
BTW, I realized that Lightburn defaults to a different serial port than the one the laser is connected to, this explains that he’s sending the “\n” and getting no response. He initially tries on /dev/ttyS0, but the laser is on /dev/ttyACM0.
When I set the dropdown to connect to /dev/ttyACM0 is when it crashes. But it doesn’t get to output a single byte to ttyACM0.
I guess the reason why once it crashes once, it crashes until the next reboot is because rebooting somehow resets the serial port it tries to connect back to ttyS0.
("ttyS*") // Standard UART 8250 and etc.
("ttyO*") // OMAP UART 8250 and etc.
("ttyUSB*") // Usb/serial converters PL2303 and etc.
("ttyACM*") // CDC_ACM converters (i.e. Mobile Phones).
("ttyGS*") // Gadget serial device (i.e. Mobile Phones with gadget serial driver).
("ttyMI*") // MOXA pci/serial converters.
("ttymxc*") // Motorola IMX serial ports (i.e. Freescale i.MX).
("ttyAMA*") // AMBA serial device for embedded platform on ARM (i.e. Raspberry Pi).
("ttyTHS*") // Serial device for embedded platform on ARM (i.e. Tegra Jetson TK1).
("rfcomm*") // Bluetooth serial device.
("ircomm*") // IrDA serial device.
("tnt*"); // Virtual tty0tty serial device.
Have you tried this with any other software on the same machine?
I think it has nothing to do with serial or the laser, because the app crashes also without any laser connected to the computer.
I have been doing some debugging, I saw you’re using QtSerialPort and tried to replicate the problem in a python script. But the closest I could get is to confirm that after a fresh reboot, calling QSerialPortInfo::availablePorts() is a normal call that returns as fast as you would expect, but if at some point I open Lightburn, from that point on calls to QSerialPortInfo::availablePorts() take about 20s (rough estimate) to return. Same behavior that I saw for Lightburn under gdb.However, in my script I can still open the serial port after that.
However, this indicates that this issue is somehow related with something going wrong in Qt.
I also saw that you’re ending the process with SIGABRT, if that helps.
In any case, I got tired of trying to find the issue and tried using lightburn from virtualbox running windows and that seems to be working.
In Linux I still didn’t find any other suitable software to try with laser cutters, but I did manage to connect to the laser with screen and send g code commands which behaved as expected.
Interesting that you support tty0tty, I also thought of using that in between Lightburn and the ttyACM0 to isolate them a bit and see if that makes a difference.
I suspect it might be that there are libs on your newer Ubuntu that are conflicting with the ones used or shipped with LightBurn. I’ve not had anyone report a crash attempting to connect before, but you’re the only one whose reported using anything past v18.
That makes sense, for the time being I will keep evaluating the windows trial. Unless I see something not working (up to now the only difference I’ve noticed is that it takes longer to start cutting), I will probably buy a license and I will try again in the future to use it on Ubuntu. I assume the license can be used on any OS, right?
