I’m using lightburn on a Creality Ender 3 S1 with 5W Laser module.
The issue is that I’m getting some weird gcode lines that are not in the job. I have an example of the latest cut. I’m making test cuts to figure out the gap in the finger joint of a box. The drawing is the jod and the photo is the actual cut.
The wrong lines are different in seperate test cuts. I have hightlighted the travel for easy understanding.
Any suggestions?
What’s the history of the laser. Are you saying this used to work and now doesn’t or are you just now trying to get this setup?
It seems unlikely that the g-code itself is bad. This seems more like either a command issue or a firmware issue. But let’s confirm.
With this same design loaded can you go to File->Save gcode, save with .txt extension, and then upload the gcode here?
Also, please confirm your machine is running Marlin.
Can you also attach a screenshot of Edit->Device Settings?
Well, the laser history is only a few test runs but I have done successful cuts like this one…
I don’t have any idea where is the problem, so I’m very open to any suggestion!
The settings are here…
Yes, it’s Marlin.
And this is the gcode (in a quick glance it seems fine)
finger test.txt (2.2 KB)
Yeah. The g-code doesn’t seem fundamentally broken. This means that your controller is likely not turning off the laser during traversal moves.
For Marlin controllers this is most typically due to incorrect Laser Control Commands being used or due to a firmware configuration issue.
Test the other Laser Control Command options in Edit->Device Settings. Inline is preferable if it works.
The reason why your test burn works is because it’s a single continuous line for the outline. It looks like you may have the same issue with the fill portion but hard to say without knowing the design.
Only M03/M05 works.
I tested the other options but although the laser did not turn on for cutting, I spotted wrong travel as well.
As for the line for the “little guy” is continuous but so is the drawing I’m trying to cut right now. In one case it goes outside off the drawing (red line) and in the other case is seems like skipping lines of the code (cyan line).
If I load the code via card instead of live connection with lightburn would it make any difference?
Assuming the issue is in the interpretation of the g-code itself then no.
What does this mean? Travel should be identical between all options.
Not following. How do you have a continuous line yet have two layers?
What’s the source of your firmware? What version is it and how was it compiled?
The drawing is a simple finger joint. Every pair was a single run. In this wood piece you see 5 individual attemps. The problem is that although the job is only the perimeter of the two parts, the red and cyan lines in the photo are wrong travel. The beam is on because it is supposed to run the perimeter but it deflects from the actual drawing.
Firmware is 3.0.4_C and it is the official firmware from Creality. I just spotted a new release to 3.2.0
You’re saying it’s going where it’s not supposed to be going but the laser is supposed to be on during that motion?
That might make sense. Looking at the specific movements I don’t think I can account for all the different motions based on the g-code.
Does this occur if you only have a single pass instead of 5 passes?
May be worth an upgrade. Do you have the ability to downgrade if necessary?
Exactly! It’s like a glitch on the coordinates.
I have several passes but it only happens once in those passes. I have run 5, 8 and 10 so far and the glitch happens once in a random pass.
I updated but I still get the glitch (blue line)
Let me revise my previous statement about running from SD Card. I think it’s worth a shot. This looks like it could be a communication issue. In that case going to SD Card could indeed resolve it.
If that proves to be the case then just a matter of sorting out the comms issue.
I proudly present the succeeded cut of the finger joint test.
I never succeeded making the gcode run from the card but I managed to find what was the problem for the glitch.
I switched to synchronous transfer mobe instead of buffered and it worked like a champ.
Nice!
Which confirms the communication issue.
However, I’m surprised transferring g-code through the card didn’t work. It should have also worked around the communication issue.
You may be able to resolve this by playing with different baud rates and going back to Buffered. Marlin devices are typically 256,000 baud.
Also, Marlin devices are typically setup to have S Value Max at 255. You may want to experiment to see if this is setup correctly.
If it’s intended to be setup for 255 then any power setting over 25% will burn as if it were 100%.
The gcode had a different structure compared to the one generated with the native program of the printer and although it started with the first couple of lines, it then stopped with a message that the consumable has depleted. Since, live connection is working, it is way better and more convenient.
I was messing with those settings in the beginning. The configuration I have is the one that works with this particular machine.
The fact that S value is 255 and Baud 250.000 are typical for Marlin is the first problem I encountered to make it work in the first place.
Finally, I can say it works fine.
Why do you suggest trying other settings in order to switch back to buffered? Is there any significant benefit?
When running complex burns it’s possible that this will result in slow burn performance, jerky motion, and compromised burn quality as a result.
If you only ever burn line shapes this may not be an issue.
Are you saying that you worked out that you need S Value at 1000 for things to work correctly?
Thank you very much for your knowledge. Since this settings configuration works for me now, I will stick to this but I will try to find if there is another possible configuration that will allow returning to buffered.
The code below is from creality’s software for the laser. As you see, the value for 100% is 1000.
;Header Start
;estimated_time(s): 93.552
;MAXX: 48.78
;MAXY: 103.11
;MINX: 41.56
;MINY: 70.22
;Header End
.
.
G92 X0 Y0 Z0
G90
G0 F3000
G1 F200
M3 I
G0X41.556Y70.222
G1X41.555Y70.222S999
My usage is for hobby and my work area is fairly small (220*220) so I don’t know how complicated of a design will I ever need to cut. But I will surely have your words in mind 
Very good.
This is interesting. They seem to be using “Inline” which helps with performance. As I recall this didn’t work for you so may be due to slightly different syntax expected.
But good to know that it’s compiled into the firmware.
It won’t be about size so much as information density. For example, try burning a grayscale image. That will be about the most demanding job your laser will face from an information density perspective. How does it work?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
