Laser behavior in M4 with rotary axis

[paukstelis]

Preface: I have read through the discussion here and thought that would solve my issues, but it has not.

I have a custom bolt-on CNC for my wood lathe that is running grblHAL on a LPC1769 (BTT SKR 1.4 Turbo). It uses an A rotary axis to move the work piece. For laser work I am generating gcode with LightBurn 1.4 using the rotary feature, which also defaults to using M4 laser mode. This is a big machine with low tolerances and relatively slow accelerations, but it is just meant for decorating turned bowls. The issue I am running into is overburn on any moves that transition into (or out of) rotary axis-only moves. Again, I thought this was the issue with the mm/min vs deg/min for feed rate and recompiled firmware to make sure I have the fixes described in the previous discussion.

Notice overburn as it transitions in/out of circle regions which correspond to A axis-only moves.

It appears to me that the laser power is not changed based on feed rate as it makes these motions in/out of these cuts. Perhaps I am misunderstanding how M4 works, but I was under the impression that was what it should be doing. I tried to do some simple tests in which I did lines along X axis (avoiding rotary) with the same defined power, but just decreased feed rates for each line. Overburn increased with decreased feed rates in those cases as well.

Any thoughts on what I should look for?

[terjeio]

Post the gcode as a start. One thought popping into my mind is about whether LightBurn changes the A-axis feedrate with changes in the diameter (the overburns look worse as the diameter gets smaller).

I tried to do some simple tests in which I did lines along X axis (avoiding rotary) with the same defined power, but just decreased feed rates for each line. Overburn increased with decreased feed rates in those cases as well.

Pictures?
Is the laser output linear vs. PWM output? Do you have a link to specifications for the laser? Datasheet?

[paukstelis]

Gcode attached.
I should note that I am doing coordinate transformation in my sender on the fly to account for the angle of the secondary rotary axis (B) that is holding the tool with respect to the linear axes. This doesn't change any feed rates, just adjusts X and Z based on that angle.

Here is the picture and gcode of the changing feed rate along X

G00 G17 G40 G21 G54
G90
G0 X0 Y0
G91
M4
; Cut @ 15 mm/sec, 85% power
G0 X10 A0
; Layer C00
G1 X-10 A0 S850 F842.81
G0 X10 A5
G1 X-10 F400
G0 X10 A5
G1 X-10 F200
G0 X10 A5
G1 X-10 F100
G0 X10 A5
G1 X-10 F50
M5

I don't really have any info about this diode laser, other than it is a one of those piece of crap 4-5W, very similar to what came on the original Ortur lasers that were advertised as 20W. The beam is very rectangular when focused.

scales.gcode.txt

LightBurn certainly does adjust feed rate based on the input diameter of the work piece, though this is consistent with other software (g-code ripper). The slight differences in overburn may be related to the curvature of the bowl taking the laser slightly more/less out of focus.

[terjeio]

Here is the picture and gcode of the changing feed rate along X

M4 mode will not change (reduce) the laser power related to the programmed feed rate, it adjusts it according to the actual feed rate achieved during acceleration/deceleration. While cruising it is the programmed power.

This doesn't change any feed rates, just adjusts X and Z based on that angle.

If I understand correctly scales.gcode is not what is sent to the controller? You sender adds Z and B motion without adjusting the feedrate?

LightBurn certainly does adjust feed rate based on the input diameter of the work piece

Then the rotary feed rate fix is not needed and might make the problem worse.

[paukstelis]

Here is the picture and gcode of the changing feed rate along X

M4 mode will not change (reduce) the laser power related to the programmed feed rate, it adjusts it according to the actual feed rate achieved during acceleration/deceleration. While cruising it is the programmed power.

Yes, that does make sense. So maybe an acceleration boost is in order on rotation axis.

This doesn't change any feed rates, just adjusts X and Z based on that angle.

If I understand correctly scales.gcode is not what is sent to the controller? You sender adds Z and B motion without adjusting the feedrate?

Correct. It just transforms X and Z (B is constant) as at queues gcode before sending.

LightBurn certainly does adjust feed rate based on the input diameter of the work piece

Then the rotary feed rate fix is not needed and might make the problem worse.

I tried grblHAL both with and without the fix and the results were the same, as far as I could tell. It seems like its these gcode lines that are suspect, since there is a ramp down/ramp up in feed rates right around the transition to (nearly) A axis-only movement:

G1 X-0.234A-0.156F1107.54
G1 X-0.214A-0.171F1011.63
G1 X-0.19A-0.186F896.59
G1 X-0.166A-0.199F780.06
G1 X-0.139A-0.211F650
G1 X-0.111A-0.222F514.24
G1 X-0.082A-0.231F376.22
G1 X-0.05A-0.24F225.5
G1 X-0.017A-0.247F75.26
G1 X0.017A-0.246
G1 X0.05A-0.24F225.5
G1 X0.082A-0.231F376.22
G1 X0.111A-0.222F514.24
G1 X0.139A-0.211F650
G1 X0.166A-0.199F780.06
G1 X0.19A-0.186F896.59
G1 X0.214A-0.171F1011.63
G1 X0.234A-0.156F1107.54

[terjeio]

Ligthburn calculates and outputs the feed rate based on engraving on a cylinder (fixed Y position, or Z for your machine?). Your engraving is not on a cylinder and you'll have to modify the feed rate (or power level) depending on the diameter where the laser beam is hitting. You will have to increase the feed rate (or lower the power level) to get the correct amount of power delivered to the cut as the diameter gets smaller.

However, I am not sure this is the (only) reason for the overburn - axis max speeds will also play into it since the actual feed rate is limited by the slowest axis. So perhaps A axis max speed is set too low? Acceleration settings may also have an impact?

[paukstelis]

Hmm...By having my B axis roughly orthogonal to the work piece and using my coordinate transformations based on this angle, I had thought that the arc lengths in rotation moves will be the same. Maybe I have to think about that some more with respect to the feed rate.

I can use my sender to adjust feed rate as well as coordinates, so I can either set a minimum feed or try to figure out the math to make more appropriate adjustments.

Thanks for your input!