Linear moving vs M67 command

Kap1eC wrote:

Yeap. It's for laser machine. I want to control output power vs M67 command.

Are you doing raster or vector images?
Where does your G-code come from?

Kap1eC wrote:

I write program which breaks any trajectory for part vs defined size. And than I try put in this parts power value.

If you can generate G-code consisting of long straight moves and circular arcs (rather than approximating arcs as many short straight lines) then you should see better performance.

Kap1eC wrote:

Okay. But how I can change lasers power on the arcs middle?

You would need to split the arc into two at the point where the power changes.
I think it would be an unusual requirement, though.
I can see that laser power needs to vary continuously when raster-scanning an image. What sort of process requires power changes in the middle of an arc?
If you want a smooth change in intensity throughout the arc then you could look at making a coordinated Z-move and linking laser power to Z. But that introduces further complications which can be reduced but not elimnated by giving the Z axis enormous acceleration limits and tiny "distance" limits.

I have a feeling that UVW axes might not be included in the kinematics calcs in quite the same way.

It would be an interesting test to run

F100
G0 X0Y0
G1 X1Y0
G0 Z.001
G1 X2Y0

and then

F1000
G0 X0Y0
G1 X1Y0
G0 W.001
G1 X2Y0

In the sim/axis/9-axis config while running Halscope to see if the latter causes less stutter in X motion than the former.

Sadly the originators of G-code never considered the requirements of laser cutters (Laser: 1960. G-code: 1980. No real excuse)