I’ve been using lightburn for the past 31 days (just purchased the license) with my Xtool D1 10w and I noticed today when cutting 3 mm ply (using a single cut layer) that all the cuts that were horizontal or vertical (X or Y axis only moving) were cut through, but any that were on a 45 degree diagonal (both X and Y moving equally) did not cut through, and only did when I reduced the cutting speed by about 30%. Visually looking at the speed of the laser dot, it seems to move along the diagonal line quicker than it does for horizontal or verticals.
Does the mm/m speed setting apply to the stepper motors or to the actual laser dot? If its the steppers then when both X and Y move 100mm/m the 45degree diagonal dot is moving at 141mm/m approx, in which case I need to reduce the speed but this then slows down the majority of the cut unnecessarily.
I am very much still learning, so perhaps there is a way of compensating for this (assuming the above assumptions are correct), or not. I don’t really want to edit the image to put all diagonals on a slower layer.
The GRBL $110 and $111 values limit the speed along a single axis. Some machines have different values for each axis.
(Edit: typo-ed $120 and $121.)
The LightBurn cut layer speed applies to the combined movement of the two axes, with each axis moving at whatever speed produces the desired speed in the given direction.
For example, consider a 100 mm/s move, with both axes limited to 100 mm/s:
Parallel to X axis: vector = 100 mm/s, X = 100 mm/s, Y = 0 mm/s
Parallel to Y axis: vector = 100 mm/s, X = 0 mm/s, Y = 100 mm/s
Diagonal: vector = 100 mm/s, X = 70.7 mm/s, Y = 70.7 mm/s
If the layer calls for a speed higher than an axis can support, the motion planner limits the overall speed along the vector’s direction.
For example, if $110=50.0 mm/s and $111=75 mm/s, a 100 mm/s layer move will behave like this:
Parallel to X axis: vector = 50 mm/s, X = 50 mm/s, Y = 0 mm/s
Parallel to Y axis: vector = 75 mm/s, X = 0 mm/s, Y = 75 mm/s
Diagonal: vector = 70.7 mm/s, X = 50 mm/s, Y = 50 mm/s
So, as a rule of thumb, don’t specify a vector speed faster than either axis can deliver, because the worst-case vector will run parallel to the slowest axis.
Thanks for the great explanation. I’m familiar with Gcode from my 3D printing so will create a simple triangle and print on a scrap of ply and see what the gcode looks like to see if I’m hitting a limit somewhere.
I’ve just created a simple 100mm right angled triangle that cuts down (Y) first, then across (X) and finishes with the diagonal. Here’s the Gcode it generated with my Xtool D1 as the selected laser and a cut speed of 200mm/m @ 90% power , start at current position. As far as I can tell the only speed setting is in the first move (I’ve commented the code with my understanding), So it looks like both X and Y are still running at 200mm/m when cutting the diagonal, giving a laser dot speed of 283mm/min unless the firmware on the laser itself does any correction??
;USER START SCRIPT
M106 S0
;USER START SCRIPT
G00 G17 G40 G21 G54
G91
M4
; Cut @ 200 mm/min, 90% power
M8
G0 X-16Y0 ; this is because the xtool is framing with the crosshairs so actual is -16mm
M3
; Layer final cut
G1 Y100S900F200 ; this is the down move and sets the power (S900) and speed (F200)
G1 X100; the horizontal line
G1 X-100Y-100 ; the diagonal back to start point of triangle
M9
G1 S0 ; laser off
M5
; return to starting pos
G0 X16Y0 ; puts the cross hairs where they started
M2
That’s the vector speed, which is appears in the G-Code as the f200 (“feed”) word.
Nope, they’re both ticking along at 200/√2 = 141 mm/min so the vector can run at 200 mm/min along the diagonal. One or the other will hit 200 mm/min when the vector is parallel to the axes.
The GRBL axis limits show up in the configuration, not the G-Code, so as long as they’re higher than 200 mm/min, it’s all good.
In principle, you can command any feed rate you want, no matter how absurdly high, and the microcontroller running GRBL will happily accept it, but the actual vector speed will never exceed the limits set by the individual axes.
I suspect you may be on the wrong track for root cause but I think worth completing the exercise. You could setup a video where you capture the motion along X, Y, and diagonal for a known distance, let’s say 300 mm in each direction. If you run at 300 mm/min it should take you 1 minute to traverse in each of those directions.
It’s possible that what may be happening is that you’re getting a voltage drop with both motors running concurrently and your laser is suffering for it. You could test for this if you have a meter.
In any case this symptom is slightly unusual as asymmetric cutting performance is usually associated with X vs Y, not diagonal. Diagonal cutting performance is generally a compromise between what you see in X and Y.
There are other possibilities for this as well. I would not rule out a firmware bug as xTool seems to have more than its share, many affecting motion control. I’d also suggest examining the material to make sure there’s nothing in its structure that could explain this.
Thanks for the suggestion, I’ll do that tomorrow (grandparenting duties today in UK due to teacher strikes!).
AFAIK lightburn can’t read controller settings from the Xtool as its proprietary, but I configured lightburn is configured using the file provided by xtool and in the device additional settings config it shows max X as 500mm/s for X and 400 for Y so much faster than the Feed value for cutting.
LightBurn should be able to read it fine. Just can’t be written back. You can check this in Edit->Machine Settings or by issuing $$ in Console.
If you freshly “read from controller” those values then they’re likely correct but in case it wasn’t clear, the values in that screen are used for Preview calculation and are not establishing speeds at the controller.
The device configuration file does nothing to set machine speed limits.
GRBL speed configuration for X and Y respectively are $110, $111 in mm/minute. But in any case, I expect you’re right that those values will be much higher than your current feed rate, especially on the X.
I ran the test this morning with a 100mm x 100mm right angle triangle and line speed of 600mm/m. Lightburn preview correctly estimated 34secs (10+10+14) but when I ran the test the Xtool D1 took 30secs - each side took 10secs each even though the diagonal should have been 14 secs. I’ve taken a video (30secs long) that shows this but the forum doesn’t allow video (MP4) files to be uploaded.
I also did use lightburn to read the controller and that did change the values, but all were much higher than the speed I was using (photo attached).
Evidence points to the Xtool controller not correctly managing the laser speed when both X and Y are moving. I’ll raise a support case with them.
Can you also try running the same test in XCS? Curious if you get the same behavior. Note that xTool maintain separate firmware for internal vs external use.
Initially when I opened XCS it prompted me to update the app and the D1 firmware (I last did that at the start of Jan). I chose not to and ran the triangle test. XCS declared it took exactly 30 seconds.
I then updated both the XCS app and firmware and repeated the test. XCS now declares it takes 32 seconds, but from cropping the video I took, the actual burn time is just over 31 seconds. In lightburn it was cutting the diagonal last; in XCS it cuts it first and based on the video timestamps it now takes just over 11 secs to cut the diagonal and jsut over 10 seconds for the other lines.
With the firmware updated I repeated the lightburn test and that too now takes approx 32 seconds, with the diagonal taking approx 11.5 secs.
So it looks like the latest firmware had had an impact but not as much as I would expect (it may be increasing power but the setting is for constant power). From zooming in on the XCS and lightburn video timelines using clipchamp it now looks like the laser is taking longer to start and stop moving (the laser is firing and not obviously moving for about .4 seconds).
Yes I changed to mm/min a few weeks ago and noticed that the Fvalue in gcode was showing 600 (600mm/min). I just changed lightburn to use mm/s and checked the gcode - the comment knows I’m using mm/sec but the F value is still 600 (so mm/min)
; Cut @ 10 mm/sec, 70% power
M9
G0 X-16Y0
; Layer text
G1 Y43S700F600
XCS as far as I can tell uses mm/sec for everything
Note that it’s not actually clear whether or not xTool support constant power mode. It’s also likely that if there are bugs in firmware it’s more likely to be associated with constant power mode. You may want to test without “regular” variable power mode.
The G-Code uses “units per minute” due to its history of running heavy CNC machinery. Up at the User Interface level, we can choose other units for convenience, but those must be converted to what the G-Code requires.
The G20 / G21 command at the top of a properly formatted G-Code program selects the unit.
I’ve long since switched to metric in the shop, unless I’m working with something uncooperative built with hard inch sizes.
[quote=“ednisley, post:16, topic:90145”]The G20 / G21 command at the top of a properly formatted G-Code program selects the unit.
[/quote]
I’m in UK so use metric for everything I can…it make maths (or math ) that much easier!
I’ve looked at the gcode lightburn is sending and it issues the G21 command, to use metric units for length.
I’ve saved and checked the gcode from a triangle cut using line with constant power and one with it deselected. The gcode for both are identical (so even with it deselected there is only the one Scommand issued in the code).
Its not stopping me cutting ply, as I have just decreased the speed when I see I have diagonals in the cut. From my experience of xtool email support I’ll probably get an initial response tomorrow or Monday.
I missed that! In the gcode for the constant power mode it first issues the M4 but then after positioning the laser to start the cut it issues the M3 command (this is the only difference from the other version). I’ll use the link Ednisley posted earlier to understand what all the other G and M commands mean.
Extract from the constant power gcode…
This is typical for the GRBL profile since M4 is considered the “normal” mode. As an aside, if you were to use the GRBL-M3 profile, M3 would be the only command ever issued.
) that much easier!