Marlin 2.0.x connection issues a possible fix suggestion

Hi everyone! My First post!
I really like LightBurn and have just bought a license.
I’ve had lots of success etching offline via SD card on my modified Chiron, but there seems to be a start-up comms issue with Marlin 2.0.x and LB 9.20
LB refuses to connect unless you get lucky with timing by pulling and reinserting the USB cable during the reset.

What I think is happening is this:

  1. Reset the connection in LB by right clicking devices
  2. A Marlin restart is triggered by serial port status lines
  3. LB then starts sending lots of G0 commands awaiting OK responses from Marlin
  4. Marlin hasn’t completed the boot cycle yet so doesn’t respond but the G0s keep coming
  5. Marlin serial buffer overflows with G0 and the firmware crashes so it never responds.

If you get the timing right by pulling the USB cable, sometimes you can get the comms initialised OK and Marlin responds to the G0 messages leaving LB ready to interact. From this point it works fine and you can etch live.

The problem is the USB hardware on some print controllers comes online immediately and serial RX buffers overflow or the ISR calls stack up before Marlin is ready to consume and respond to the commands.

I can actually reproduce the issue by queueing up a load of G0 commands in a terminal and sending them before Marlin 2 comes online.
Octoprint has a similar issue that can be resolved by increasing the comms retry timeout.

My theory to fix this is to add a delay to the Marlin interface in LB, so after a connection reset, LB waits for a few seconds to allow Marlin to boot and output the welcome message before starting the stream of G0 messages. 5 seconds would be a good starting point but this may need to be tweaked.

I’m a dev manager for a software company and have been using Marlin for years, I’ve added code to the official repo too, so I would be happy to send any debug info and test fixes with you.

If I roll back to an older version of LB (I went back to v6.00) the comms works just fine.
Nick

Here’s my debug log

22:32:28.610 D: Looking for port: “COM5”
22:32:28.614 D: – candidate port PID 60000 VID 4292
22:32:28.614 D: mfr: “Silicon Labs”
22:32:28.614 D: prod: “Silicon Labs CP210x USB to UART Bridge”
22:32:28.614 D: name: “COM5”
22:32:28.614 D: - found matching port name
22:32:28.614 D: Found port: PID 60000 VID 4292
22:32:28.614 D: Manufacturer: “Silicon Labs”
22:32:28.614 D: Product: “Silicon Labs CP210x USB to UART Bridge”
22:32:28.614 D: Name: “COM5”
22:32:28.622 D: Port open succeeded
22:32:28.661 D: EV: 1001 took 21 uS
22:32:28.661 D: “starting” busy: false state: 0
22:32:28.661 D: EV: 1001 took 4 uS
22:32:29.670 D: “Attempting to connect” busy: false state: 1
22:32:29.670 D: “Connecting…” busy: false state: 1
22:32:29.673 D: O: “G0\n”
22:32:29.927 D: “Connecting…” busy: false state: 1
22:32:29.931 D: O: “G0\n”
22:32:30.186 D: “Connecting…” busy: false state: 1
22:32:30.190 D: O: “G0\n”
22:32:30.450 D: “Connecting…” busy: false state: 1
22:32:30.453 D: O: “G0\n”
22:32:30.710 D: “Connecting…” busy: false state: 1
22:32:30.714 D: O: “G0\n”
22:32:30.971 D: “Connecting…” busy: false state: 1
22:32:30.975 D: O: “G0\n”
22:32:31.231 D: “Connecting…” busy: false state: 1
22:32:31.238 D: O: “G0\n”
22:32:31.497 D: “Connecting…” busy: false state: 1
22:32:31.505 D: O: “G0\n”
22:32:31.759 D: “Connecting…” busy: false state: 1
22:32:31.766 D: O: “G0\n”
22:32:32.023 D: “Connecting…” busy: false state: 1
22:32:32.027 D: O: “G0\n”
22:32:32.288 D: “Connecting…” busy: false state: 1

I have seen some similar issues to this trying to communicate with my laser engraver because of other software I have that grabs it first…

Cura (and probably other) 3D printing software grabs them if it sees them.
Q GroundControl drone control program
Mission Planner drone control software.
Arduino development library

If any of those are running then its just a crap shoot as to who gets the port.