Mm/sec should work fine. That is what all of my testing is done with.
The only reason mm/min has the “better for diode” distinction is they are typically slower than Co2. With the S1 that is not really true anymore.
3 Likes
I just used Joes settings to install Lightburn using the xtool method. Seems to work fine but I’m now noticing my engraves seem lighter color wise as well as depth of engraves is different. I still have the clack shack set up as well and the difference depth and color of engraves is totally different. I’m using pass thru mode on a particular file and they come out different. Any idea where or what I could look at to see what they are coming out different? Glad I found this place. Total Lightburn newbie for sure. Now, off to go figure out how to make a macro for the darn lid thing…HAHA. Thanks in advance
Lablover27…when you refer to the “darn lid thing” are you referring to the fact that the lid must be closed in order to focus and frame while using Lightburn? If so there is a fix that works. If you set up the S1 using Lightburn’s built in settings just click on the console tab and you will find buttons to disable and enable the lid detect.
1 Like
I made the test. Here are differences between old GRBL profile VS new xTool profile where Constant Power option is missing.
Slightly more power was needed to match the average line darkness. But that is not the issue.
Is it possible to add this option in to the xTool profile too?
1 Like
Those lid-detect buttons are not there by default. Care to right click on them and give me the codes in them? Ill update the device file I’ve been sharing on the forum.
1 Like
Lid Detect Enable M802 S0
Lid Detect Disable M802 S1
Sorry, I have been using them for quite a while and thought that they were there by default. Forgot that I had entered them myself. They work great. Allows the user to fram and re-position the workpiece without having to constantly lift and shut the lid.
1 Like
I am working on figuring out how to manage constant power. Thanks for pointing it out. We will update when there’s a beta to test
3 Likes
Hi all,
Was planning on opening a thread for the issues I have been having with my new xTool S1, but I just saw this one is about pretty much the same topic, so I am chipping in here.
First of all, to all lightburners: thanks for the great software, love it. Worked like a charm with my D1 Pro for the past 2 years. Have upgraded to an S1 a week ago, and sadly, have not been able to get it to work as perfectly in conjunction with Lightburn. Yet.
The first issue,
as described by @raine, was due to setting up the profile for the machine with the .lbdev file from the xtool website (the “old” profile, as I will refer to it from here on). I followed the instructions from @joespanier (Setting up xTool S1 with new xTool device type in LB 1.7 Beta) for the new manual profile setup (hereafter referred to as “new” profile), which eliminated the triangles-instead-of-squares bug. So far so good.
But this new profile introduced a new problem regarding power. As you can see, with identical settings, the new profile over-burns. At least it would seem so at first. Upon closer inspection, I realized it is still using the same power as with the old profile, but it is not modulating the power according to the actual travel speed of the laser head. What I think normally happens when you set a speed of 50mm/s and a power of 100%, is that the laser will only actually emit 100% when it is in fact moving at a speed of 50mm/s. At the start of a line, so when it is accelerating from 0mm/s to 50mm/s, I suppose it will gradually increase the power output in direct relation to its actual speed, until the travel speed is reached and the full power coefficient is maintained. Then, approaching the next corner, it slows down and down-regulates the output power proportionally, until it speeds up again. This seemed to work perfectly well with the old profile - does not behave the same with the new profile.
It reminded of me of something I had seen while doing some testing in XCS-Software. There, you have 2 options when you are tuning your settings for any vectors in your design: “Score” or “Cut”.
Since i was running this test-job via Wifi, I was certain these two different modes must be accessible via gcode commands (because when you use WiFi connection with your S1, the job is being sent to your machine as a tmp.gcode file, which will then be run when you press the button on your laser). So i used wireshark to intercept the .gcode files generated by XCS, sent one job for the “Score” function, another job for the “Cut” function, and compared the 2 gcode file with each other. These two lines are the only differences:
I suppose M3 is sort of a “constant” mode, and M4 a “dynamic” mode. Knowing that both are possible and we are give the choice within XCS-Software, I supposed that from Lightburn, the “old” profile was probably setting up it’s gcode commands with M4 (since we had nice modultation there), and the “new” profile had now incorporated the M3 command somehow. To check my theory, I created a simple .gcode job from Lightburn, once with the old profile, once with the new, and compared the two:
Suprise: that seems to be the source of the over-burn issue. The “new” profile uses M3 S0 (not sure what the S0 stands for though), while the “old” profile exports a gcode file with an M4 command. I created another test-file with the power-speed-grid, this time, I exported it using the “new” profile that used to over-burn, but instead of sending it directly to the machine, I saved it as a gcode, then went and opend it in text-editor and replaced the “M3 S0” with “M4”, leaving everything else as it was, and this worked:
So to get perfect results for scoring material with Lightburn, we would simply need to be able to choose whether we want to execute the M3 or the M4 command. Ideally, on a per layer basis. This would be even nicer, giving us, just as XCS does, the choice whether we want full cutting power independent of travel speed for a whole layer (mostly to cut through), or whether we want an evenly and consistent burn-line to evenly score our designs onto a surface.
Unfortunately, this is not something we can access as end-users, it is not within the parameters you can set in the gcode tab of the device settings. It seems to be hardcoded into the machine profile.
@joespanier: would it be possible to incorporate this in the next update of lightburn? Who would be the right person to contact for this feature?
It could be as simple as a “2 choice switch” in the layer options (when you double click on a layer), giving you the option of either “constant” (M3) or “dynamic” (M4) power output? If not on a per layer basis, at least change it to be M4 by default? (I’d rather have always nicely modulated power than the unpredictable over-burning.)
The 2nd issue:
With the source of the over-burn issue identified, I still had a remaining problem. You may have noticed in all test-images above that my text is very wavy/scraggly/wobbly. It doesn’t just happen on Text though, also in other shapes and straight paths:
At first, I thought this might be a mechanical issue, something loose within the machine itself. But running the same job via XCS software returned a perfectly nice result, no wobble whatsoever.
The second thought was, maybe XCS just clamps velocity. But it seemed to run the job at the same speed as Lightburn did, as far as I could tell from eyeballing it.
Now some might say “this is way too fast for such small detailed shapes”, and I agree. In fact, even if you set your speed to 300mm/s, the text is never actually lasered at that speed, since the laser head is constantly slowing down, changing direction, and accelerating again. The laser head never actually reaches the full speed you programmed. So even if you set your speed at 300mm/s, your text might actually only be lasered with 20mm/s average speed. So you might as well set the whole job to that speed. Fair enough. And actually, with 20mm/s, the wobble is almost imperceptible in the test run with Lightburn. BUT: if your design also incorporates a long straight line across the whole working area, by setting the speed at 300mm/s, it will travel very fast on that line. Travelling that long line with 300mm/s will save you lots of processing-time. So you might end up with 3 minutes for the text, + 2 seconds for a 300mm long straight line. Whereas by setting 20mm/s for the whole job, you have probably the same 3 minutes for the text, but an additional 15 seconds for the straight line you could have accelerated much more. What I am trying to get at is: you don’t buy a Ferrari, just to drive around with it in first gear only.
Okay, the S1 might not be a Ferrari, but it is definitely capable of those high speeds (not on small details as agreed, any laser will cap itself and slow down there) and still gives perfect results without any wobble when run via XCS-Software. Long story short: as it is clearly a software based issue, I suspected it might be another gcode command that creates or prohibits the wobble from happening. So I created a simple Test-Job to create .gcode files from XCS and compare them with the .gcode file of the same design run via Lightburn to compare them:
I tried copying all the commands, one by one, in the top section (before the beginning of the actual coordinates) of the .gcode generated from XCS. Nothing changed. I always kept getting the same wobble in all the tests run via Lightburn. I even replaced the top section as a whole in the gcode file and ran it via Lightburn, still got the wobble. Until I changed the last thing that differed between the two Gcode files. Turns out, the solution was much simpler than what I had expected: the only thing left to try was changing the way the coordinates themselves are output in the .gcode. Notice how - from XCS - the gcode created always lists both X and Y values on one line? Whereas the gcode from Lightburn only writes out the coordinate that changes (for straight lines, always just either X or Y) on one line. This seems to be the culprit. Because when I copied the coordinates from XCS-gcode over to the Lightburn-gcode (without touching the original top section at all), the wobble disappeared!
It seems that the xTool S1 gets confused if it only gets fed 1 coordinate at a time (probably something to do with interpolation of movements?! Beats me 
). As soon as the gcode feeds both coordinates simultaneously, it works just fine. Here are those two gcode files from Lightburn (+ the one from XCS), if any body cares to try on their S1 to replicate the findings (I did actually substitute the M3 S0 into M4 as well, just to get nice consistent burn throughout - but that has nothing to do with the wobble of course).
gcode_fromLB_noWobble(resolved through coordinate change).txt (743 Bytes)
gcode_fromLB_withWobble.txt (624 Bytes)
gcode_fromXCS_noWobble.txt (1,0 KB)
I don’t know how complicated it is in terms of programming, but would it be possible to change this too for the coming update @joespanier? Or is this a bug that xtool need to fix via the firmware for the S1?
Hoping both of these issues (M3 to M4, and coordinate output) can be resolved timely, that would make me a very happy customer once more 
Kind regards from Switzerland,
Frédéric
3 Likes
Thank you so much for making this post and digging into it as much as you have. These are all the problems I’m seeing with my S1. The “wobble” I solved just like you mentioned, choking down the speed for everything. I hope this assists the Lightburn team in solving these issues!
I decided to try the gcode M3 S0 to M4 change,
Here are the results: The left side is the M3 S0, and the right side is the M4.
Same gcode that was generated with the Lightburn XTool S1 profile.
3 Likes
Will there be a beta release to address the M3 to M4 issue? Saving to Gcode and modifying it myself is becoming tiresome. Additionally, what feedback is there on including full X/Y values instead of just X or Y?
Thanks!
Maybe if you create a Custom GCode device you could automate that change.
Unfortunately, won’t work on Custom Gcode as Xtool has some special magic in the protocol. so Xtool Controller is required.
Asked the Dev team to build a Beta @raine that I could share.
Should have some news tomorrow.
3 Likes
Nice work.
I know that xTool has a messed-up G-code parser. But realize that they will not admit it, and will instead say, “Our XCS works flawlessly.”
As promised, RC candidate for 1.7.04
Could you guys give it a good try and see if the issues are fixed?
All feedback here will be welcome!
https://release.lightburnsoftware.com/LightBurn/RC/LightBurn-v1.7.04-RC-1/
Thanks so much. I see it addresses the XTool issue of having to use mm. Will give it a good test.
Correct.
It should fix these issues as well as the M3/M4 power modulation.
And a few cleanups and fixes to the protocol.
Do please test it with your normal preferred workflow without workarounds.
Did some Cutting and Engraving material tests as well as some actual projects with cutting, engraving and lines. Everything came out flawless. All burns were consistent without any over burned areas. Was also able to do all this with inches selected and not having to select mm as before.
Thank you so much for staying on top of improving the S1’s functionality within Lightburn. You guys have been great. I do not like creative space at all and use Lightburn exclusively.
2 Likes
This is great news.
Please keep testing and if you find any odd behaviour report here or support@lightburnsoftware.com
Thanks @gilaraujo, have done some testing.
Issue Nr1 with M3 vs M4 has been resolved. Power is now nicely modulated when laser is moving at different speeds, in order to get consistent burns throughout. We are now able to choose whether a layer is supposed to use M3 or M4 command via the “use constant power” switch when double clicking on the layer. Great work 
Issue Nr2 however has not been addressed though. I still get the wobble on straight lines.
As described in my last post above, once again, this seems to be caused by only outputting single axis coordinates whenever performing linear moves. When the Y axis coordinate does not change during a linear movement, Lightburn does not output that coordinate to the gcode file. That’s where the xTool S1 seems to create the wobble. Because when I manually add in the missing coordinate (so if the gcode only had an x coordinate on any given line, i add the previous Y coordinate to it) the wobble disappears.
Lightburn does export both coordinates on the same line correctly whenever both axes are need to perform a movement, as seen here in this example with the letter “m”:
All curved parts of the “m” are nicely cut without wobble, as soon as we get to the vertical lines, only the y coordinates are output, and the wobble sneaks in.
Nobody else ran into this with their testing?
It seems it is only to be appearing when going over a certain speed, so you might not run into it when staying below 35mm/s. I start seeing it quite pronounced around 50mm/s, stronger the more you go up in speed. But again, as stated in my previous post, when running the same jobs through XCS software, you can go as high as 300mm/s and the wobble still does not appear.
@gilaraujo Have you discussed this with the development team? What’s their take on it? Is this possible to include in the next release? (I sincerely hope so, I am stuck to XCS for the moment because of this and I’d love to get back to using Lightburn)