LightBurn sending G-Code twice

LightBurn seems to be sending the same set of G-Code commands twice. I’ve attached two examples below: one showing framing, and one showing running a program.

I’m trying to setup a TelNet Grbl device, and currently using a “dummy” TelNet server (Python script) that is emulating a Grbl handshake.

  • Running on Mac but I don’t think this matters.
  • Tried both 1.6.03 and 1.3.01 with same results.

There is this post suggesting the “Gerbil-STM” option fixes it. Unfortunately Gerbil-STM doesn’t allow TelNet.

What I don’t understand is:

  • What about the handshake could cause LightBurn to behave this way? Is there an option that enable/disable double-sending?
  • As shown in the run program example in the screenshot. LightBurn sends the G-code twice, once “raw” and a second time in a more annotated or “verbose” format. Seems quite strange. Why would it do this?

Leo at Roly Automation : )

Hi Leo.

Ideally please send the files below also to support@lightburnsoftware.com

Could you share your Edit > Device settings screenshot

Then a LBRN + Saved Gcode please

Seems though its stoping the stream - as said “stream completed in 0.00” then sending again.
The 2nd send is without intervention?

Thanks for the reply Gil. I sent the files to support@lightburnsoftware.com as well.

Please see screenshot of the Device Settings page below:

Just tried synchronous mode as well. It sends G-Code line by line the first time around as you would expect, but still follows up with the annotated version of the same G-code, and the second time it’s a batch dump.

With regards to “Stream completed in 0:00”, the TelNet server currently is replying “ok” as quickly as possible, which causes the stream to finish in a very short period of time. The 2nd stream of G-Code is without any intervention. Interestingly, the second time send is not accompanied by the “Starting stream” and “Stream completed in …” messages.

Leo

Wondering if the server is echoing back the stream buffer through the serial port.

Some firmware do this for debugging purposes.

We would have to get the DEV team to take a look into it - however, to do so we would need to replicate the whole setup.

Could you describe fully - here or via support@lightburnsoftware.com - how to replicate the test environment please?

Understand that is a possibility by I think in this case TelNet server echo is not the cause, since the second stream of G-Code is different from the first. It contains more information like

“; LightBurn 1.6.03
; GRBL device profile, current position
; Bounds: X0 Y0 to X148 Y133”

Which the server would not know ahead of time.

I’ve sent the python script for the TelNet server, along with the .lbdev file as well. Thanks again!

1 Like

Hey @gilaraujo I figured it out, somewhat.

  • The repeated sending of G-Code will only happen in Current Position mode, and not in Absolute Position mode
  • It will only happen in current position if the “?” prompt sent prior to the stream was not responded to with a status report message similar to “<Idle|MPos:0.000,0.000,0.000|FS:0.0,0>”

So these are three possible scenarios, out of who knows how many:

  1. Absolute position mode. LightBurn does not send “?”, and will always only send the G-Code once, and in its bare-bones format i.e. only G and M commands without comments
  2. Current position mode. LightBurn sends “?” prior to stream, but only gets “ok” as an response. It will then send G-Code twice, once without comments and once with comments such as “; LightBurn 1.6.03 ; GRBL device profile, absolute coords”
  3. Current position but the “?” is gets the two responses: “ok” and “<Idle|MPos:0.000,0.000,0.000|FS:0.0,0>”, LightBurn will only send G-Code one time, similar to #1 above

Why does LightBurn send the G-Code twice when there is no status report message? I suppose it’s some sort of insurance. Since the status/position of the machine is unknown, LightBurn sends it more information to guide it.

My question is: Is it possible to request LightBurn send the commented/annotated version of the G-Code stream every time? It contains information that is very helpful such as bounding box, layer name and operation type. Our machine could really use this information (for reasons, of course) :stuck_out_tongue:

@Nick_Makin I saw your post about a similar issue maybe this helps.