Laser power reduction with changing feed rate


Grbl is governed by two standards documents. If a function is not in one or the other of those documents then that function falls outside of the realm of grbl.

The commands for changing feed rate (F) and spindle speed (S) are documented there. So technically, laser power is not addressed by the standards. It is an adaptation for using lasers which doesn’t require a change in grbl. It’s like using a screw driver to open a paint can. The function of a screw driver is not to open paint cans, but it will function that way if you want to use one to open a paint can.

As far as changing feed rate or spindle speed within a single G-code line, I’ll have to check on that, but I don’t think it’s supported.

[Edit] Indeed if you send a G-code line with more than one F command or more than one S command grbl returns an error (error: Invalid gcode ID:25).

Acceleration is controlled by runtime parameters that the user enters into Grbl. There is some adaptive code inside Grbl that will slightly modify the acceleration to blend the acceleration from one segment to the next, but I don’t think that it changes the acceleration within a segment.

But it could be supported within one of the functions that is part of spec, if what I read was correct. (unless we’re using the word “function” differently here)

Without this ability, I guess I would need to know what the maximum speed I could set without creating an acceleration/deceleration (such that I could get an even burn across the entire line). Is that dictated by the grbl or some config? (I don’t think I saw any config variables that matched that description) But even with that knowledge, it seems unfortunate. Not being able to utilize the full power of the laser, causing the etching to take longer. And on top of all that, the accel/decel are there for the benefit of the machine, to help ensure it doesn’t get off position, so it would be best to keep that functionality in tact, but have the laser scale with the acceleration/deceleration. The F command provides the desired top speed for the line, and the S command specifies the “spindle speed”, so it makes sense that this change wouldn’t apply to routing. But if laser mode is being added to the firmware, one would think a smidgen more support for it would be worth it (assuming there are sufficient bytes remaining to fit it on the chip)

Let me invite Jeff, @picengravertoo into the conversation as he has worked these issues out in the programs that he sells.

I’m inside grbl looking out, he is outside grbl looking in.

one would think a smidgen more support for it would be worth it (assuming there are sufficient bytes remaining to fit it on the chip)

This might be an issue for Sonny. He is the person who has taken the lead with grbl. He has just added laser support to grbl in the 1.1d beta release.

1 Like

Sonny added Dynamic Laser Power Mode to the beta v1.1 laser grbl. It’s enabled with a M4. If the feedrate slows, the laser power (PWM) decreases. As long as there is no dwelling with the S commands, I don’t see any use for this, but what do I know? :laughing:

When a M3 is executed, his grbl runs in standard laser mode (like Larry’s grbl) which we take full advantage of having an S command & Feedrate on each command line to expand the shade range with the laser. When the S command power value increases, the feedrate slows. This can be set by a percentage of the full feedrate setting. Example: If a minimum PWM setting is 0 and Maximum setting is 255 with a 100 IMP set max feedrate and the FRC (Feed Rate Change) percentage is 25%, white will run with a S0 F100 and black at S255 F75. The shades in between will be variable S & F.


See Sonny’s comment here:

1 Like