Lightburn on the Wainlux L3 with roller

Hello there everyone! I am one of the Kickstarter backers of the now infamous Wainlux L3 Laser engraver! I have been fumbling around with this thing all day and scouring the net for any help, I recall the piracy issues spoken of in the KS comments and that the creator of lightburn itself had to step in. While this was unfortunate it did peak a lot of interest in the program and its compatibility, that being said I have downloaded the “Trail Version” to see if it would help me in using this device.

I suppose this is a 2 pronged question…

  1. Can this Wainlux device be setup with Lightburn as is or does it HAVE to be upgraded to the GRBL firmware (the reason I ask is there was talk of locking down Lightburn to not read the Wainlux - which seems to be the case )

  2. This Wainlux engraver has a dual roller that connects to the printer its self via usb (from what I can see on the internals it looks like it is setup standard on one motor and reversed on the other) however when the wainlux has the grbl firmware setup on it and the roller plugged in the terminal gives a ‘error 20 unsupported or invalid g-code command found in block’.

SO I am here on behalf of all the Wainlux backers that want to do the right thing and support your software, I would be more than happy to purchase when the trail ends if i can get it working.

Thank you very much for your time and any assistance you may be able to offer

I’m not familiar with the intricacies of the device but it would need to be running a compatible firmware for LightBurn to control it. GRBL Is a supported firmware. I suspect the alternative is proprietary and likely not supported.

What is the purpose of the dual roller?

Are you referring to the Console within LightBurn or this is something else?

When specifically does this occur? Can you paste the entire context of the error?

LightBurn itself doesn’t control hardware. It makes requests to the controller which manages all hardware. If there’s an issue it’s likely to do with GRBL configuration or hardware settings.

Went to the site, there is no mention of the ability to use any other software, but theirs. Lightburn doesn’t do wifi as far as I know.

As @berainlb points out, it has to speak ‘grbl’ for Lightburn to be viable.

Good luck

:smile_cat:

Hey there thank you for responding,

I’m not familiar with the intricacies of the device but it would need to be running a compatible firmware for LightBurn to control it. GRBL Is a supported firmware. I suspect the alternative is proprietary and likely not supported.

Ok, the device itself ships with a usb drive that has both the proprietary firmware and a compatible gbrl firmware. The creator of lightburn and the creators of the Wainlux had some ‘issues’ over piracy and there was talk of ‘removing support’ for the wainlux engravers, which leads me to believe that lightburn should work, but if the creator of lightburn has hobbled the software it would be up to them to help the honest backers out. I hope that they see this and chime in.

What is the purpose of the dual roller?
The roller is for printing on cylindrical objects, the wainlux has the ability to etch curved surfaces due to an autofocusing z axis, the roller plugs into the etcher and should take over the x axis movement,

Are you referring to the Console within LightBurn or this is something else?
The console / terminal within Lightburn itself - sorry I should have been a bit clearer on that

When specifically does this occur? Can you paste the entire context of the error?
The error occurs when using the rotary / roller setup window when testing the roller
the errors are
on the A axis:
Waiting for connection…
[VER:1.1f.20180715:]
[OPT:VMZ,35,254]
Target buffer size found
ok
Homing
ok
ok
ok
ok
ok
<Idle|MPos:-228.000,-275.000,0.000|FS:0,0|WCO:-228.000,-275.000,0.000>
ok
Starting stream
error:20
Unsupported or invalid g-code command found in block.
On or near line 2:
Stream completed in 0:00
error:20
Unsupported or invalid g-code command found in block.
ok
error:20
Unsupported or invalid g-code command found in block.
ok

and on the Z/X axis - (same error)
<Idle|MPos:-228.000,-275.000,0.000|FS:0,0|Ov:100,100,100>
ok
Starting stream
ALARM:2
G-code motion target exceeds machine travel. Machine position safely retained. Alarm may be unlocked. (Right-click the ‘Devices’ button to reset the connection)
On or near line 4:
Stream completed in 0:00
[MSG:Reset to continue]
ok
Grbl 1.1f [’$’ for help]
L3_GRBL_v1.0
[MSG:’$H’|’$X’ to unlock]
[MSG:Caution: Unlocked]
ok

LightBurn itself doesn’t control hardware. It makes requests to the controller which manages all hardware. If there’s an issue it’s likely to do with GRBL configuration or hardware settings.

This was also my line of thought, but considering the comments made by the Lightburn creator in the comments section of the Wainlux Kickstarter I am hoping there is an easier way to get this sorted with a bespoke Wainlux compatible setup in lightburn.

if @LightBurn could help me get this thing working properly I know of at least 20 people that would be forever grateful and if they haven’t bought the software they would in a heartbeat, I am only in the trail to try and see if i can get this thing working and if i have success I’ll buy it, I have no need for it otherwise. That being said, if there is anything I can do to help get it working I’m at your disposal, I don’t know much about these things but I have worked on many 3d printers and gcode based machines, I’m quite technologically adept.

I checked the controversy and it looked like Oz was eventually satisfied with the resolution. If Wainlux were banned I trust @Lightburn wouldn’t have done it in a subtle way. More like loud and clear.

I assume this is a hardware solution? As in no input required from g-code commands to keep it at the right height.

The roller takes over X-axis movement? That’s really unusual for a rotary. I’m wondering if that’s the basic issue. LightBurn assumes Y, Z, or A for rotary.

This is actually not the same error.

You likely also need to disable soft-limits while you are using the rotary. Disable $20=0.

So I want to make sure I get it… so you’re expected to orient the rotary vertically? And the Y–axis is used to scan up and down while the rotary moves along the X-axis?

I’m not aware of a way to make an X-axis rotary to work in LightBurn…

I checked the controversy and it looked like Oz was eventually satisfied with the resolution. If Wainlux were banned I trust @Lightburn wouldn’t have done it in a subtle way. More like loud and clear.
Ok, that being said the device setup process should pick up the Wainlux using the find laser function during setup or at the very least as this isn’t the only Wainlux on the market there would be a Wainlux catagory in the manual selection, but both of those options are not there which led me thinking they might have been removed - as I saiid this is my fiirst experiance with this program and I have checked through the fourmn and seen other Wainlux users using Lightburn

I assume this is a hardware solution? As in no input required from g-code commands to keep it at the right height.
the unit has a 2 laser setup 1 for burning the other for focusing, there is a button on the top of the device that does and auto focus and the device is supposed to adjust focus ‘on the fly’ for curved objects.

The roller takes over X-axis movement? That’s really unusual for a rotary. I’m wondering if that’s the basic issue. LightBurn assumes Y, Z, or A for rotary.
I’m honestly not sure of the orientation but using the dodgy software that comes with the device other people have been etching things with the roller taking control of the x axis

This is actually not the same error.
sorry - should have meade this clearer
the A error is the first one
and the Z and Y error is the second, I didn’t post both the Z and the Y because they have the same output

You likely also need to disable soft-limits while you are using the rotary. Disable $20=0.
I will give this a try, honestly anything is worth a shot at this stage, any other suggestions you have to help would be greatly appreciated - I am your guinea pig!

So I want to make sure I get it… so you’re expected to orient the rotary vertically? And the Y–axis is used to scan up and down while the rotary moves along the X-axis?

Sorry i was mistaken it looks like the roller is setup to take over the Y axis
I may have this wrong ( coming from 3D printers the orientations i work with are
Z axis = vertical up and down
X axis = horizontal left and right
Y axis = depth front to back
if looking at the device from front on.
the rotor has the rollers alligned left to right in the instance i’m describing

I’m not aware of a way to make an X-axis rotary to work in LightBurn…
My mistake as described above

If the x axes is left to right and the rollers run left to right that leaves the rotary on the Y axes…

:smile_cat:

Find My Laser depends on the right firmware being installed, the right driver being installed, the laser having a COM port, and it responding as appropriate to LB serial USB requests. LB is unaware of any specific models, only controller types. In this case GRBL. This isn’t entirely true as the DSP version does have knowledge of specific controller models for specific security checks.

There are plenty of times where Find my Laser does not work even for other well supported models.

Ok. Sounds like a hardware solution and will assume that unless I hear otherwise.

Ah… misunderstood.

Okay. Then there may be hope yet.

If you’re not expected to disconnect the Y-axis when you setup the rotary I’m going to assume it’s setup to use Z or A. You need to figure out which. You can use the Rotary Setup to test rotation. Apparently it’s not A as you’re getting the unrecognized command error. So likely Z… or possibly it is actually Y. Just work out which one is able to get your rotary to move.

Once you can coax movement then it’s just a matter of working out the rest of the configuration.

By the way, have you tried a regular burn with LightBurn without using the rotary?

Another question:
Have you tried running the laser in LaserGRBL?

Find My Laser depends on the right firmware being installed, the right driver being installed, the laser having a COM port, and it responding as appropriate to LB serial USB requests. LB is unaware of any specific models, only controller types. In this case GRBL. This isn’t entirely true as the DSP version does have knowledge of specific controller models for specific security checks.

There are plenty of times where Find my Laser does not work even for other well supported models.
Right, now I’m getting a clearer picture,

Okay. Then there may be hope yet.

If you’re not expected to disconnect the Y-axis when you setup the rotary I’m going to assume it’s setup to use Z or A. You need to figure out which. You can use the Rotary Setup to test rotation. Apparently it’s not A as you’re getting the unrecognized command error. So likely Z… or possibly it is actually Y. Just work out which one is able to get your rotary to move.
I have tried all three options available and nothing yet, I will however see if i can coax something by unlocking as you suggested previously and tinkering with gcode too see if i can find something.

Once you can coax movement then it’s just a matter of working out the rest of the configuration.
heres hoping
By the way, have you tried a regular burn with LightBurn without using the rotary?
I have succeeded with a regular burn on 3 out of 3 attempts, the hardware seems to be fairly decent from what i can tell.

Another question:
Have you tried running the laser in LaserGRBL?
I have loaded it up in LaserGRBL but not attempted anything yet, I will give it a shot and hopefully get some more info on this

And thank you so much for all your help - even though you are asking questions it is helping me to change my mindset as to how this thing communicates with LB!

Glad to help. I’m particularly supportive of people breaking new ground or trying things DIY.

A couple of additional suggestions:

  1. If you’re able to disassemble the laser so that you can see the board, it may very well label the port to determine how it’s supposed to be addressed.
  2. You could try these commands in Console to determine what triggers the rotary:
G91 
G0 Y+5
G0 Z+5
G0 A+5

Hopefully the rotary responds to one of the movements. I think this should be basically the same as what happens if you push the “Test” button in rotary but…

1 Like

1. If you’re able to disassemble the laser so that you can see the board, it may very well label the port to determine how it’s supposed to be addressed.
Imgur: The magic of the Internet
here is a link to some photos of the board, the lettering on the connectors is gb2,ga2, ga1,gb1 and the port identifier is g1. which of course makes a great load of sense! /s

  1. You could try these commands in Console to determine what triggers the rotary:
G91 
G0 Y+5
G0 Z+5
G0 A+5

I thought that I should test that the roller is actually working so this morning i flashed back the stock firmware and tested in the app Wainlux provided and was able to connect and burn a test on an aluminium can i had laying around, so the rollers do actually work. Having said that flashing back to the GRBL firmware and testing roller functionality was a bust, none of the commands resulted in anything happening apart from the laser moving left to right and back and forth.

The program that Wainlux provided is completely written in Java, I unfortunately don’t know the first thing about cracking it open and seeing how the program works, if you have any pointers for me I would love to hear them, I think the best option moving forward now is finding out how this java app works and the calls it makes to communicate with the roller, then I can possibley reverse engineer something that will get us up and running in LB

I wonder if this means that the connector is only using a USB form factor but is actually just standard 4-pin stepper connectors.

Maybe I’m missing something. Is this all you need? Or do you mean the entire gantry was moving back and forth… not just the rotary.

What happened when you ran the listed commands? Did you get an error message? What exactly occurred?

I don’t really think this will be of much help. What’s really required is to determine if and how this functionality has been exposed in GRBL. Did you get a chance to try this in LaserGRBL?

Can you run these commands from Console and return results:

$I
$$
$#
?

Other thing I’m thinking is that worst case, you could wire the rotary to the Y axis port. Might need an adapter to do so. But based on the board I don’t see why this wouldn’t work.

as requested commands run in LaserGRBL

Maybe I’m missing something. Is this all you need? Or do you mean the entire gantry was moving back and forth… not just the rotary.
when in the LB roller setup window
Yaxis
<Idle|MPos:-225.000,-275.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>

ok

Starting stream

ALARM:2

G-code motion target exceeds machine travel. Machine position safely retained. Alarm may be unlocked. (Right-click the ‘Devices’ button to reset the connection)

On or near line 4:

Stream completed in 0:00

[MSG:Reset to continue]

ok

Grbl 1.1f [‘$’ for help]

L3_GRBL_v1.0

[MSG:‘$H’|‘$X’ to unlock]

[MSG:Caution: Unlocked]

ok
laser head moves right 10mm then jumps back to home.
Roller does nothing

Z axis
<Idle|MPos:-228.000,-275.000,0.000|FS:0,0|WCO:-228.000,-275.000,0.000>

ok

Starting stream

ALARM:2

G-code motion target exceeds machine travel. Machine position safely retained. Alarm may be unlocked. (Right-click the ‘Devices’ button to reset the connection)

On or near line 4:

Stream completed in 0:00

[MSG:Reset to continue]

ok

Grbl 1.1f [‘$’ for help]

L3_GRBL_v1.0

[MSG:‘$H’|‘$X’ to unlock]

[MSG:Caution: Unlocked]

ok
laser head moves right 10mm then jumps back to home
Roller does nothing

A axis
<Idle|MPos:-226.500,-275.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>

ok

Starting stream

error:20

Unsupported or invalid g-code command found in block.

On or near line 2:

Stream completed in 0:00

error:20

Unsupported or invalid g-code command found in block.

ok

error:20

Unsupported or invalid g-code command found in block.

ok
laser head moves right 30mm then moves smoothly back to home
roller does nothing

What happened when you ran the listed commands? Did you get an error message? What exactly occurred?
G91
G0 Y+5
laser head moves 5mm back
G0 Z+5
Soft limit
[MSG:Reset to continue]

G0 A+5
unsupported command

is there a library of gcode commands that lasergrbl uses or that i can use in LB? we are close i think!
if I knew a bit more i think we could get this thing working

FYI, the GRBL commands can be run in either LB or LaserGRBL.

Can you rerun this command? I think you missed a $ in it:

$$

Looks like you still have soft-limits enabled. Can you turn off any try again?
Run this in Console:

$20=0

Please run the $$ command ahead of that so you have a reference of your current settings.

Where exactly is home on the laser?

I think the Z-axis motion looks promising as it didn’t complain of a syntax issue.

Here’s a reference for GRBL settings:
grbl/settings.md at master · gnea/grbl · GitHub
Here’s a reference to Linux CNC g-code commands which seems to be a de facto standard:
G Codes (linuxcnc.org)

Where exactly is home on the laser?
when the stock Wainlux firmware is running home is the back left corner, when the GRBL firmware is running it is the front left corner,
I think the Z-axis motion looks promising as it didn’t complain of a syntax issue.
ok, interesting as the z (i would have thought at least) was the up / down used in focusing the laser head?
thanks for the GRBL library I shall have a play and see what i can get out of this thing!

Ok, side thought, is it at all possible to ‘unlock’ the rest of the axis options? My guess is it would have to be done on the firmware that is written to the device. I have noted the current active axis’ are F,N,S,T,X,Y and Z with A giving and ‘unsupported command’ error. It got me thinking how Wainlux could potentially ‘hobble’ the device so you HAD to use there firmware to use the roller… I wouldn’t put it past them, shady tactics and all that!
I think i might see if i can bust open the firmware they supplied us with and have a peek…

Does that mean the machine has limit switches at both corners?

Looks like you’ve got an offset configured. Is this intentional?

Did you run these commands immediately after a homing operation?

Normally it is used for vertical height as you say. However, I’m guessing the auto focus system isn’t handled as a Z-axis component as I suspect it’s a hardware solution.

$20=0 - did you disable soft limits?

How did you come up with the active axes? I was hoping something in $I or $$ would have revealed the axes but didn’t see anything.

This looks to be standard GRBL which would normally be limited to 3 axes: X, Y, and Z. Not clear if it’s been modified. Other more advanced GRBL derived firmware I’ve heard of up to 6 axes if I’m remembering correctly. There could certainly be more.

It’s possible… or they just didn’t bother to do more.

Does the auto-focus work when using LightBurn? Curious how they’ve handled that.

Does that mean the machine has limit switches at both corners?

Looks like you’ve got an offset configured. Is this intentional?
This is from the firmware

Did you run these commands immediately after a homing operation?
yes

Normally it is used for vertical height as you say. However, I’m guessing the auto focus system isn’t handled as a Z-axis component as I suspect it’s a hardware solution.

$20=0 - did you disable soft limits?
yep

How did you come up with the active axes? I was hoping something in $I or $$ would have revealed the axes but didn’t see anything.
i went through and did G0 a-z+1 and recoded the ones that came back as active, alas none triggered the roller
This looks to be standard GRBL which would normally be limited to 3 axes: X, Y, and Z. Not clear if it’s been modified. Other more advanced GRBL derived firmware I’ve heard of up to 6 axes if I’m remembering correctly. There could certainly be more.

It’s possible… or they just didn’t bother to do more.
also possible

Does the auto-focus work when using LightBurn? Curious how they’ve handled that.
initiating it in laserGRBL worked, I didn’t check it in LB,

I don’t think that’s the root cause of the issue you’re seeing, but LightBurn doesn’t like working in a negative coordinate system. Might be worth eliminating the offset.

G92 X0 Y0

when the laser head is home (bottom left corner) it registers as x0 y0
Running the commands again just in LB
$20=0
$I
[VER:1.1f.20180715:����������������������������������������������������������������]
[OPT:VMZ,35,254]
Target buffer size found

$$
$0=6
$1=255
$2=0
$3=2
$4=1
$5=1
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=0
$21=0
$22=1
$23=0
$24=600.000
$25=3000.000
$26=250
$27=2.000
$30=1000
$31=0
$32=1
$100=62.000
$101=62.000
$102=62.000
$110=9000.000
$111=9000.000
$112=9000.000
$120=1000.000
$121=1000.000
$122=1000.000
$130=228.000
$131=275.000
$132=1.000
ok
ok

$#
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:-228.000,-275.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
ok

?
<Idle|MPos:-228.000,-275.000,0.000|FS:0,0|WCO:-228.000,-275.000,0.000>
ok