Laser does NOT travel correctly

I’m currently using Lightburn 1.7.03.
Running on MSIGS75 Stealth

Self-made laser… Ortur laser 10w
Arduino Uno with CNC Shield
A4988 controller chips

Laser setup:

$0=232
$1=87
$2=0
$3=0
$4=0
$5=0
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=0
$21=0
$22=0
$23=0
$24=1000.000
$25=300.000
$26=250
$27=2.500
$30=1000
$31=0
$32=1
$100=80.000
$101=80.000
$102=250.000
$110=3200.000
$111=3200.000
$112=500.000
$120=1000.000
$121=1000.000
$122=10.000
$130=200.000
$131=200.000
$132=200.000

I have a similar setup on a much larger format using TB6600 controllers and it is working fine. I seem to be missing something.

The last picture shows what the laser is to trace. It travels to the correct initial location and moves in an arc in the negative direction for the circle. It travels from 360 degrees to 270 degrees and then 270 to 360 ( arcs on each). It then travels one more time from 360 to 270 in arc and then at the 270 degree point it travels in a negative direction from there ( as if it were at 90 degrees) to 180 degrees. Overall laser etch would be like a slanted “S”,

Producing a diagonal S from a circle in several steps could be happening because of backlash.

I imagine that your homebuilt machine is not prone to deflection because enthusiasts build machines for themselves and busniesses build machines for production.

In the Laser window, click Optimization Settings, toggle the ‘Hide Backlash’ feature, then run the job again.

Another test that’s often worthwhile is confirming the GCode is being generated correctly.

To proceed with this, select File, then save GCode. If you attach that file here, I can run it through a simulator to confirm the behavior of LightBurn is as expected. If you’d like to check the GCode behavior, there’s a free GCode viewer in Notepad++ that works nicely.

Thanks for your info. I will see if I have backlash hidden or not. I will get back with you shortly. Again, thank you!

Well hiding backlash just made it do a single pass at the slanted “S”. But, it did change the operation anyway.
circle.gc (2.6 KB)

I have found that the absolute coords is not the same location on the grid as current position and user origin. The latter two come up the same but are in the “middle” of my grid. Also, in the g-code it looks like the “bounds is showing different than X0 Y0 to X381 Y355.

Could that be the culprit?

To better understand how this works in Lightburn:

I keep finding that I’m going through the A4988’s. I’ve thought about rewiring to take them off the board and wire in my TB6600’s. They are a more robust controller and is what I am currently using on my 29”x49” laser that I use for most of my engraving.

This one was to be able to take to craft shows and do onsite personalization.

1 Like

Just a question: - How did you found the $0 value?
https://github-wiki-see.page/m/gnea/grbl/wiki/Grbl-v1.1-Configuration

I just found out that it is a coordinate issue. If I have the square upper right part of grid, it etches correctly. However if I use a circle or anything that has to combine x,y coordinates, it does not etch properly. If the square is in any other quadrant on my grid, it does not etch properly. It stops without completing the square. Again, no difference in the circle or other complex shapes.

The License for the NCnetic GCode previewer has been changed. Trial is watermarked. I like it. I may just buy it. I will report back.

The circle image is generated correctly in the GCode from LightBurn.

Thanks @parsec I think you’re seeing the crux of the issue.

I’m inclined to offer a possible counter-argument:

The settings associated with $0 and $1 combine to make a total of 319 microseconds.

Because of this selection, your maximum engrave and travel speeds are limited to just over 90 inches per minute.

To Confirm this, without changing the timing ($0, $1) or anything else please retest with the following settings:

Set $110 and $111 to 2200 mm/minute which is roughly 82 inches/minute and
… set the engrave speed for your at 75 inches per minute and
… reduce the engrave power by 25% and retest.

Please report back if this resolves the unwanted behavior.

Please check my arithmetic below if you like.

Given: 319 microsecond total pulse timing: Step pulse length $0=232 + Step idle delay $1=87
Confirm that 100 inches/minute engraving speed is possible or not.

$0 – Step pulse, microseconds recommended 10 us : actual setting 232us

$1 - Step Idle Delay (Always on = 255) : actual setting = 87us

100 inches per minute:

Metric speed limit of the controller:
$100, $101 and $102 – [X,Y,Z] steps/mm 80, 80
$110, $111 and $112 – [X,Y,Z] Max rate, mm/min 3200, 3200


Find Maximum Pulse timing at 100 inch/minute:
100 inch per minute is 100inch/min * 25.4mm/inch = 2540 mm/minute

Commanded steps per minute: 2540 mm/minute * 80 steps/mm = 203200 steps per minute
Commanded steps per second: 203200 steps/minute * 1 minute/60s = 3386.66 steps per second.
Commanded step timing: 0.0002952 seconds per step… or 295 microseconds.


Find: MAX Speed based on total pulse timing: inches / minute

Time required per step ($0 + $1) = 232us + 87us = 319 microseconds.
Working it backwards from here: 1/319 E-6 = 3134.796 steps per second

3134.796 steps / second * 60 seconds / minute * 1mm / 80 steps * 1 inch / 25.4mm = 92.56 Inches per minute.

Maximum traverse speed: 92.56 inch / minute
Maximum traverse speed $110, $111 (mm/minute) :92.56 inch / minute * 25.4mm/inch= 2351 mm / minute.


Test case above to confirm.

1 Like