Lightburn 2.2 PreRelease xTool S1 feedback

Thank you sir!

That $L comes from the Start GCode in the device profile I sent. Apparently, this is not needed with the new protocol in version 2.2

Did the job still run, despite the red notice in the console?

You can remove those lines in “Edit > Device Settings” (Alt + F3) G-code tab here:

I now corrected this in the profile I posted.

The job ran, but it ran at the HOME location, rather than the location of the laser when I pressed Run "with ‘current position’ selected.)

That’s correct for 2.2 RC-3. I found out about this here:

Why do this before RUNNING a job but NOT before FRAMING the same job? The difference in behavior is disturbing.

I absolutely agree.
As mentioned, that’s going to change. We’re currently investigating if it’s us sending the machine home, or if the S1 does that on its own.

‘current position’ runs as expected in the earlier release.

We’re aware of that. The 2.2 RC-3 uses a new xTool protocol.

Am I right in thinking XTool has 2 ways to talk to it? That would make life ‘interesting’ for you.

That’s correct. And not the only thing that makes our lives interesting :slight_smile:

can you save the g-code out of a job that is homing before running and post it here please

How would I do that?

“Save G-Code” in the Laser Window.
That’s the exact code that we send the machine when you click Start.
Save the file to the computer and upload it in a reply here.

Sorry I didn’t get back to you sooner. Some automotive problems took up my last 2 days.

Bottom Line Up Front: RC4 seems to have fixed this problem, but I still get the “unrecognized command at line 1” message.

Details: I loaded RC4, connected to the laser, selected the laser and XTool S1-40w LBDEV, and loaded my simple test. Here’s what the app looks like AFTER running everything:

Then I moved the head (using Move commands, not manually), and pressed Frame. Here’s the generated codes:
frame2.gc (556 Bytes)

Finally, I pressed Run. The head did NOT move to home, it drew the box where it was positioned. Here’s the generated codes:
run.gc (556 Bytes)

(I went back and edited the XTool LBDEV to remove that offending command as described earlier by @Aaron.F. Later today, I’ll do one more confirmation test.)

I added another post to the RC4 thread, but just wanted to mention here. RC4 has introduced a new issue, where the first time I press Run, I get an error, but pressing Run a second time produces the expected result.

After one test, it seems RC4 has -fixed- the “Run not where Frame’d” problem on my XTool S1 10w. I still get the error message from the LBDEV file. That’s a change from what I saw in RC3 and RC2, so I wanted to report it here.

well… Earlier I said that the "Frame at current, but Run at Home’ problem went away in RC4.

But I now have another problem. Sequence is “Frame”, then “Run”. Frame works OK. Run throws an error and nothing burns. If I press Run again, the job executes. Here’s the console (highlight added)

ok
[xTool V1 text g-code job: 556 bytes]
Starting stream
$L
G90
G0 F3000
M110 X1 Y1 Z1
M109 S1
M7S1
M96 S0
G90
G92 U0
G0 F9600
G1 F1000
G91
M109 S1
M96 S0
M110 X1Y1Z1
M7 S1
G91
M4
M15 S1
G0 X33Y27
G1 X0Y21S600F6000
G1 X-33Y0
G1 X0Y-21
G1 X33Y0
M15 S0
G0 X-33Y-27
M6
M110 X1 Y1 Z1
M109 S1
M7 S0 N0 D10
M96 S0
M109 S1
M96 S0
M110 X1Y1Z1
M7 S0 N0 D10
Stream completed in 0:00
ALARM:cancel
[MSG:Pgm End]
M2036 S1
[xTool V1 text g-code job: 556 bytes]
?
MPos:19.98,109.96,17.11,0.00
ok
[xTool V1 text g-code job: 556 bytes]
Starting stream
$L
G90
G0 F3000
M110 X1 Y1 Z1
M109 S1
M7S1
M96 S0
G90
G92 U0
G0 F9600
G1 F1000
G91
M109 S1
M96 S0
M110 X1Y1Z1
M7 S1
G91
M4
M15 S1
G0 X33Y27
G1 X0Y21S600F6000
G1 X-33Y0
G1 X0Y-21
G1 X33Y0
M15 S0
G0 X-33Y-27
M6
M110 X1 Y1 Z1
M109 S1
M7 S0 N0 D10
M96 S0
M109 S1
M96 S0
M110 X1Y1Z1
M7 S0 N0 D10
Stream completed in 0:00
M15 A1 S1
M15 A1 S0
ok
[MSG:Pgm End]
M2036 S1
M15 A1 S0
[xTool V1 text g-code job: 556 bytes]

Here’s the output GRBL code, failure first, success second:
fail1gc.gc (556 Bytes)

works1.gc (556 Bytes)

It’s the same code between the failed Run and the Successful run, except for the date.

And the settings for the laser:


I removed the starting command from the laser defs that was causing the previous (non-fatal) warning.

Interesting.
I compared the two gcode files you sent. Appart from the time in the comment, they are identical.

What error do you see on the first attempt?
I can only see the " ALARM:cancel" in your post, but that happened after “Stream Completed”

Does a third attempt to run the job start successfully?
If you restart LightBurn: Is it always the first try that throws the error?

Reasonable questions. Let me go back and try a couple things:

  1. what happens if I press Run a third time? Does it burn again, or does it throw an error?
  2. I’ll restart Lightburn and do the Frame Run Run sequence.
  3. I’ll restart Lightburn and do Run Run (no Frame first)
  4. I’ll run RC-2 and capture the results from there, both the recorded behavior and the GBRL files.

Anything else to try?

  1. Frame, Start, Start, Start, Start: First and 3rd Run produced the error, 2nd and 4th ran as expected. So it seems every other Run faults.


No meaningful information with the error.

  1. Relaunched RC4, Frame, Start, Start. Nothing new from this

  2. Restarted RC4, set Z. Moved the head. Then did Start (without Frame first). Run threw a fault. Pressed Start again. Cut as expected. Did that twice, first Start fails, second one Runs.

  3. Loaded RC2, set Z. Moved head through commands. Frame drew where the head was. Pressed Start. Head moved back to Home and cut there, did NOT throw an error. Here’s the output from RC2:
    rc2 box.gc (545 Bytes)

add: I did look at the RC4 and RC2 generated files. There are definitely some differences, but I don’t know enough to comment on them.

@Aaron.F : Should I try this on RC5? I didn’t see any hints in the release notes that anything relevant changed.