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