Marlin - job stops early, same GCode sent via pronterface works

I run Marlin 2.0.5 (custom build) on an SKR 1.4 board.

I have similar issues as per Jobs stop after a short time (20sec - 1 min)

I recompiled and flashed new firmware with the suggested RX_BUFFER_SIZE

-//#define RX_BUFFER_SIZE 1024
+#define RX_BUFFER_SIZE 128

The job stops early when run from lightburn, and even leaves the laser still on (!) It stops after 2-4 seconds (so just 4-10 gcode instructions), but not in the same place.

Saving the gcode and running from pronterface or octoprint works fine, the full laser cut is made.

On Linux I’m using lightburn 0.9.16, on Ubuntu.

I’ve tried:

  • Linux Ubuntu lightburn
  • Windows 10 lightburn
  • Without any USB extension cable - just short ‘blue’ cable the SKR 1.4 board came with

The Console shows

Starting stream
Layer C00
echo:Unknown command: "M9"
M106 P0 S0
M106 P0 S255
M106 P0 S0
M106 P0 S255
M106 P0 S0
M106 P0 S255
M106 P0 S0
M106 P0 S255
M106 P0 S0
M106 P0 S255
Stream completed in 0:00

But there are more instructions that that, it appears to just stop sending them. Note it ends on an S255 (laser on).

It seems also the gocde contains M8/M9 instructions even if I have ‘air assist’ disabled for that device; but it appears harmless.

I’ve double checked that my firmware with RX_BUFFER_SIZE 128 is running - (I changed the machine name, and observe the new name appearing on the LCD)

Trouble streaming data creality cr-10s with ender-5 board creality diode laser had the trouble too, and fixed via

it is set to 4 in marlin and needs to be configured to 16 or 32

but unclear what ‘it’ was, since the mention of 16/32 is not what Oz asked for which is 128.

BLOCK_BUFFER_SIZE is something that can be set to 4/8/16/32 etc. but I don’t think that’s what’s being discussed.

I’ve recompiled my firmware to set baud rate to 115200 in case that helps, but no change.

I’d highly value any suggestions! I’m hoping to get this working before trial period expires so I can evaluate more fully.

The RX buffer size number is a minimum. If yours was previously set to 1024, leaving it there isn’t hurting anything - it’s “how much data can LightBurn send the controller before it chokes”. :slight_smile:

I’m adding support for the “ping-pong” method of communication, as this does not force-feed the controller until the RX buffer is full. Ping-pong mode sends a single command, and waits for the ok response before sending the next one. This method limits the throughput, so rastewr performance may not be as good, but it is likely what Pronterface is using and is less sensitive to poor comms handling on the controller side, electrical interference, etc.

Thanks Oz. I’ll look out for that. Hopefully we can reset trial period if it comes after current trial expires.

Let me know if there’s something you’d like me to try on the controller - I’m happy recompiling the firmware, sniffing the serial pins, etc.

Yes, that’s easy to do on our side. I’m not sure what our timing is going to be for the next release, but we may do a “cleanup” release with a few small new features before too long (IE weeks).

The 0.5W laser stopped working (very dim, wouldn’t etch). So I’ve ordered a whole “20W” Ortur Laser Master 2 instead of mounting a laser on to the marlin-based printer. When that arrives, I’ll ask for a trial reset if possible. Thank you!

It is - When the machine arrives, in LightBurn, copy the trial ID text into an email to support at lightburnsoftware and ask for a reset.

The laser arrived within the lightburn trial period; I’ve gone ahead and bought a full licence now. No need to extend trial, thank you!