Incomplete job on Linux version with grbl Ortur LM2

LightBurn Hardware Compatibility Ortur Lasers
,
1

Hi, I have problem with LightBurn (1.1.04 but also previous one) on Linux (Manjaro), connected to a Ortur LM2Pro (updated to the last firmware).

All operations as home, Jog, frame… are working, so connections is OK.

When I start my job it is executed for a while, but it stop working after few seconds/minutes.
The software reports busy, the console report no more gcode message and no errors, but all is off.
Some time pressing stop it exits (see log 2) some time no.

The machine is working because closing and restartin LightBurn it restart to communicate and jog.

console.txt (37.4 KB)
console2.txt (38.5 KB)

Changed several usb cables but not solved. I attached the linux console output from where i executed LB.

Not all the files present the problem. Some files are completed with no problems. I attach also the file I’m working on. It fails during the first pass of the first external perimeter.

I then changed OS (same notebook, but win10 with same LB version and same file). In this case no problem and I can complete my job.

But for me use only windows version is not an option, because I create my files and I work 99% on linux.

I’m a sw developer with experience in serial protocol too, so please tell me if I can investigate or I can do more debug.

smartphone_stand1_3mm.lbrn2 (13.6 KB)

The current file settings are speed 2000@5% to not waste other material, but the same with original settings 200@95%

2

The lbrn file looks great.

I see that you’re capturing the communication from a linux console and not the LightBurn Console.

I suspect that the requested speed is causing the problem.

If you’d copy and paste the LightBurn console info I may be able to see an error or alarm message more easily.

3

Thanks John for your reply.

Here the output from the LB console… but I can’t see any error.

console_lb.txt (10.1 KB)

Strange thing is it stop exactly at the same point. Repeated several times and the last gcode is the same (about 67%).

But using windows it works perfectly.

Tried other baud speed bot nothing changes.

Then I tried setting the sync mode (instead of buffered) and it stops early (about 13%).

Here the log from LB console. It reports less info with the same settings enabled.
console_lb_sync.txt (2.2 KB)

4

Just another info: if I export the gcode and send it using Candle (GitHub - Denvi/Candle: GRBL controller application with G-Code visualizer written in Qt.) it works to 100%. So I can confirm my OS settings are not the problem. The communication between my linux machine and my Ortur works.

5

@OrturTech - Hi Gil, any thoughts on this?

6

could you please give me some information about the serial handshacking?

For each transmitted Gcode command does LB wait for OK or else? What the difference between buffered and not?

I think I could be able to sniff the serial traffic (using usbmon module on linux) but I’m not sure how LB works.

7

This may be what you’re looking for:
https://lightburnsoftware.github.io/NewDocs/DeviceSettings.html

I would be interested to know if Enable DTR worked for you.

8

Enabling DTR does not solve :frowning:

I can attach a log file with strace call (read and write). I see a lot of strange messages, but I can’t understand the meaning and what lightburn wait for.

Tell me if I can do more test.

Tried also old versions of LB but same results. In the past, when I decided to buy a license, was my first test with lasercutter, so about 10/20% of failed test I thought was for my bad operations.

But now I have a 100% reproducible issue and I would to solve to no waste materials on other projects

strace_logfile.txt (72.3 KB)

10

Still having the problem!

Tried to upgrade to new 1.2.0.0 release hoping something changed, but I have the same issue.

Tried to save the gcode file and then, instead of open lbrn file, I executed directly the gcode from LB button, but it stop in the same position.

I repeat I can complete the job using other software like Candle.

I think is a problem in LB communication in Linux version only.

Comparing the console flow between LB e Candle, I can see LB sends gcode commands more quickly, like it is not waiting for a confirmation answer… possible?

Could this cause problems on some messages? Is there a way to see that on console?

11

When you say this works in Windows but not Linux is this on the same computer and same USB port?

These type of disconnects are almost always caused by one of a handful of issues:

  1. bad cable or usb port
  2. static discharge causing short of usb port
  3. fluctuation in mains power from other equipment on the same circuit
  4. sleep or timeout of usb port

If your windows test is on the same computer and port then that can rule out a bunch of these.

12

Thanks for your reply.

Yes, I tested in Windows on the same laptop and same USB port.
I also changed USB port but same problem.

pt 1: changed several cables, last with 2 ferrite

pt 2 and 3: the job stop exactly in the same point every time, as described. I think fluctuations and static discharge should be random

pt 2, 3 and 4: using other software, as described, I can complete the job without issues.

13

For static, this isn’t entirely random. For example, engravings with consistent back and forth motion are more likely to build-up static charge and reliably short the port whereas line operations may not build enough to charge to trigger the scenario. If running the same job multiple times, the time to build critical mass may be around the same time.

However, you’re saying the job stops at exactly the same point which is definitely not what I would expect.

To confirm, you ran the same job on Windows and Linux?

What baud rate have you configured for the port? I find it highly unusual that this would be working less reliably in Linux. I’d expect the opposite for something like this.

14

Yes. I use exactly the same file. And also exporting LB file to gcode file, in Candle I can complete the job but in LB I can’t complete the job using the “execute GCode” button

Tried different baud rate and also sync/buffered mode. Usually I configure 115200 (that is the default in other sw that are working) but also with lower baud same results (eg 9600)

15

Seems most variables have been eliminated.

Perhaps try downgrading to previous version to see if behavior is different.

Also, what distro and version are you running?

16

Already tried with previous version, same results.

I’m using manjaro distro 64bit.

In the weekend I did other test using the usbmon module - thanks Linux, I can hack :wink: - and wireshark to capture gcode transmitted and ortur response.

I attach captured file for LightBurn (buffered and sync) and Candle: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free

(sorry for wetransfer link but forum don’t permits upload pcap files)
Use this filter: (usb.dst==“1.66.2” && usb.endpoint_address.direction == OUT) || (usb.src==“1.66.2” && usb.endpoint_address.direction == IN && usb.data_len >0)

I think the problem is on the amout of data LB sends to laser board, or the timing.

In buffered mode LB sends all the gcode in almost 6 packets. Then the board answer OK to single GCode command but at some point it stop (may be the internal memory is limited?).

In sync mode is almost the same. It sends each CGode command waiting for OK. But the laser send OK when it receive, not when it execute (standard behavior) so I think (if the timing is too much high) it fill the rx buffer and then stop to response OK.

In both cases the laser is not blocked. If I close and reopen LB I can send new GCode.

In Candle seems it use a method similar to LB buffered mode, but with less GCode commands for each packet.

And may be the timing is more relaxed.

In this case the job works well.

Finally:

  • Can LightBurn developer confirm the analysis?
  • Is there a way (or workaround) to send commands with more relaxed timing?
  • Why this occours to me only? Is not the Ortur LM2 PRO a large used machine? Sounds really strange

Thanks

17

Just to be sure, you are using the “GRBL” device and not “GRBL M3”, or “GRBL-LPC”, or “GRBL-STM” correct? My Ortur LM1 which is probably 2 years old has been working fine with LB or at least as far back as the move to version 1.00

I would also go in and look at which USB driver is being loaded so you know you’re getting USB2 capabilities. Probably look at htop to see what your system performance is like when running this just to see if something else isn’t messing with performance. Even an older PC with 4GB of RAM should have no problem here unless something under the hood is messing with USB performance.

I’ve even run LB from an AtomicPI and had no problems and now I use an old x86 tablet running Linux for the Orture but it does have a USB3 interface…

18

Yes, I’m using GRBL device.

Other jobs are running well. The problem occours only for some files. I attached the problematic file at the first post because is an example of replicable problem.

May be (just a personal opinion) when a program reach a long segment, the laser continue to receive GCode without executing them (it is still moving) and then the memory fills up.
But I can’t be sure of that.

The same gcode file executed by Candle seems to be processed in more time, and perhaps this gives the laser time to empty the buffer.

19

Just to summarize before I give this a shot on my LM1 with the laser module unplugged(just testing motion, don’t need burning).

The file uploaded stops at the same location in the file most of the time it is run when it’s LB on Linux.
It doesn’t happen with LB on Windows(same machine/USB port/cable).
It doesn’t happen when using Candle GCode sender but does happen when LB is imported and sending the same GCode.

When running the GCode via Candle GCode sender app the full runtime of the project is longer than when run via LB(both Windows and Linux)?

I won’t be able to test this until tonight and I have LB on KUbuntu 18.04 and LB on a tablet running Ubuntu 21.10 and it will be a Ortur Laser Master 1.

20

Thanks Doug for your support.

Your summary is ok, but I never tried Candle in windows too, just Linux.

Waiting for your test results. Meanwhile I’m trying to get another Linux PC from a friend, to test other distro and PC.

Thank you very much

21

the two drawings in the smartphone case file don’t fit on the LM1 since it’s only 160x150 but I scaled it so the parts were 62.50mm across(each) and ran it 5 times without error. BTW, the file loaded with speed of 33.33mm/s and power at 5.0 loaded into LB 1.2.00

It just dawned on me @itarozzi that maybe there’s a power power supplies issue at work here. These PSs have been known to fail and there might be something different about USB performance causing s glitch which stops GRBL. Throwing arrows in the dark here since the configurations which work and don’t work makes it tough to pin down.

I would also make sure you’re powering up the Ortur first and then connecting the USB on each and every test case. Consistency helps weed out the oddities.