Working on this 
Thank you for the detailed report!
Will report back asap
Would you be so kind to provide
a) your Edited GCODE test files for the M and the shape
b) both LBRN
That way maybe others in the thread could test and replicate the results?
Any updates on adding both coordinates to eliminate the wobble?
Hi Frederic
The Dev team was made aware of this.
Is being studied and replicated. I personally do not own an S1, so I can’t replicate it myself.
Will need to be a little patient as the dev team looks into this.
Sure, here are the files for replicating the wobble:
gcode_fromLB_17_1.7.04 wobble m.txt (1,1 KB)
gcode_fromLB_15_1.7.04 wobble graph-line.txt (674 Bytes)
Both G-code files can be exported using this Lightburn file:
wobble_01.lbrn2 (230,8 KB)
And here the corrected gcodes that don’t have the wobble result anymore:
gcode_fromLB_18_1.7.04 wobble m - resolved (manually added missing coordinates) gone.txt (1,2 KB)
gcode_fromLB_16_1.7.04 wobble graph-line - resolved (manually added missing coordinates).txt (818 Bytes)
Thank you for these.
We do understand what Xtool S1 is expecting from your earlier reports. We are trying to understand why, and especially why this becomes a bigger requirement on higher speeds.
Being tested as we speak should not be an impossible fix.
However, as this is an attempt to codify an Xtool protocol, we also must confirm this change will not interfere with other machines (ex . D1)
Yes, I have the same issue. I just got used to slowing down the speed. Take a look and test the acceleration from XCS and Lightburn. Let’s say, engrave the longest line you can in one axis, and time the travel. I think XCS actually changes the acceleration values. Lightburn seems much faster to me.
Just for clarification for the developers: The S1 has different hardcoded acceleration values for the X and Y axes. The X axis can be much faster than the Y axis. xTool advertises 600 mm/s, but in my observation, that can only be achieved on the X axis. The Y axis cannot accelerate and decelerate fast enough to achieve this speed. This means it is much faster to engrave horizontally than vertically.
@frm178 Can you export and compare the G-code with the engraving strategy from XCS? Maybe both strategies at once, like a filled square with outlined edges. They might coded the controller in such a way that if there is no second coordinate, it maxes out the acceleration, like rapid movement. But if there is a second coordinate, it slows down the acceleration to prevent shaking with those wobble artifacts. If this is true, I would say it is a neat workaround, but it is outside of G-code standardization and therefore bad practice, causing headaches. Nothing new from China.
Thank you for replicating Martin
Just for clarification, I think that the wobble is caused by extreme acceleration and deceleration. The whole machine shakes with faster directional changes at maxed-out acceleration.
As mentioned above, it is something everybody can live with. Just slow down with speed. The advantage is very small (in seconds), but it can still be achieved through reverse engineering this piece of s**t controller made / programmed by xTool.
When engraving, the maximum acceleration and deceleration in the X-axis is advantageous. You literally save minutes, and the machine is sturdy enough alongside that axis. Look at the “m” example. The wobble occurs only when you decelerate from the X-axis and go vertically in the Y-axis. There is no wobble the other way (from Y to X).
However, these values are not advantageous when cutting or engraving along vectors, like the example at the beginning of this thread. In those cases, you want lower acceleration/deceleration to avoid hitting the resonance frequency.
This is actually a whole revolution in 3D printing, known as input shaping.
Hope this elaboration helps.
If Frederic’s findings are correct, though, this is not necessarily the case.
In other words, if it was a physical limitation of the machine, both test files would yield the same results.
We have a parsing/planner issue - and Devs are looking into this.
What I meant is, that LB is hitting the physical limitation, because it doesn’t provide the code, as the “engineers” at xTool expecting it, and that this might be a feature they intended to use as a switch between Cut/Score and Engrave strategy.
When I use XCS, accel and deccel seems much slower. I can make a test tomorrow, when I take a video of a same 300 mm line score with XCS and LB and count the frames, to see if the accel and deccel is changing by the strategy selected in XCS.
That is why I ask @frm178 to extract G-code for engrave strategy in XCS. It might looks quite the same like the one from LB.
I understand what you meant yes.
I have my theories about why this is, but as I do not have an S1 on hand, it is just that!
The dev team is celebrating the Holidays today, but I am certain it won’t take long to confirm the hypothesis above.
We have to ask a bit more patience
Okay, so I downloaded the Wobble file that Frm178 posted and ran a test. Before running the test I thought that there was a possibility that the wood was shifting from not being secured down so I ran the test twice, once with the wood unsecured and then again with the wood secured by rare earth magnets. The funny thing is that both of my test burns didn’t produce the same wobble lines. There is a wobble in the upper left but that’s all I could detect. I have enclosed pics.
Right. I have a few devices in the PC not in my head.
On the phone I couldn´t check the options.
Here is the gcode that XCS sends to S1 when running a job with a simple square in score mode, and the same square next to it in engrave mode.
gcode_fromXCS_score and engrave square.txt (22,0 KB)
I suppose you suspected that it will feature only single X-coordinates commands in the gcode? If so, you are correct. Your theory about different interpretation/acceleration depending on whether one or two coordinates are provided may be right.
Not sure how this will affect the dev-teams solution/options to get rid of the wobble though, since the thing causing the wobble seems to be within the S1-controller and how it translates the gcode commands it is sent. So the actual cause/fault in not in Lightburn, but it might still be necessary to change what lightburn sends to the machine in order to get it to work corretly (as it obviously does with XCS).
Interesting, thank you for running the test.
Stupid question 
:
Can you verify that the actual settings of the layers are really the values that the text describes? (layer 1, 300mm/s @60% power, etc). It seems a little strange that the first line is so much darker than the following 3 lines of text, since it should all be the same speed/power ratio.
It almost looks like you do have some wobble in the line-graphic on the right side, but less pronounced than on my machine. Can you take a closer shot of it?
It might just be the grain of the wood and a bit misleading therefore, maybe you can run the test again on some flat surface like a simple sheet of white printer paper?
If the culprit is really resonance introduced by the rapid movement (which I believe it is), then it is a much bigger pain to get rid of without decreasing the speed and accel values.
I suppose you suspected that it will feature only single X-coordinates commands in the gcode? If so, you are correct. Your theory about different interpretation/acceleration depending on whether one or two coordinates are provided may be right.
Here, xTool seems to go around that issue with two modes. When you engrave, you can bump up the acceleration and deceleration in X-axis so they can hit the 600mm/s mark they claim. The wobble is immediately canceled by the reverse direction.
But, you cannot use these acceleration/deceleration values when scoring as the machine starts to hit its physical limits. So, they need to decrease the accel/decel values somehow in the process. It seems they decided to go by modifying the G-code interpreter.
I think that M-code would be a much better option for this. But, you can expect anything from our Chinese friends. This is such a bad practice and causes us a lot of unnecessary work.
What the devs of LB can do is change the G-code output in the same way. When you select Fill, it will work same as now. But when you select Line, it will generate both coordinates no matter what.
Ok, so I wanted to test this again and get it posted because this thread is due to close in 3 hours. I did the burns on paper to eliminate the grain of the wood effecting the results. The first image is 300/60 the second is 250/70, and the third is 200/70. I zoomed in close for the photos. All three exhibit the wobble.
Thanks for doubling down. 
I was really curious if and why your machine wouldn’t behave in the same way. But it now seems coherent with my results
Maybe someone in contact with lightburn forum administrators can extend the lifetime of this thread until all issues are resolved?
Not Anymore
Do keep discussing please!
This is exactly what we need. A bigger sample size to test and validate results.
We are monitoring closely
