No problems here.
When Sonny implemented the laser code in 1.1f he included some changes to the way G-code works in order to include some safety features. Safety features are not a bad idea at all, but there are some problems with the implementation.
First problem is that he changes the way some of the G-code commands function which are not in accordance with the G-code spec that grbl is based on, so if you have a program that generates G-code by the standard, then it will not function as expected when run via grbl 1.1f when running in laser mode (spindle mode works well with no issues that I know of).
Second problem is that there have been reports of lasers turning on at full power when it was not expected by the operator when using 1.1f. This one is the one that really bothers me.
G-code generating programs have to be modified to use the laser properly with version 1.1f. An example of a program that does this is PicSender. A program that does not do this is the Vcarve flavors. I haven’t really looked into it, but it might be possible to make a Post Processor for the Vectric products to handle 1.1f with the laser. But the high end software folks are probably not going to go to the effort for a machine like the Xcarve.
It just makes me nervous that someone could get hurt if they don’t know the characteristics associated with using a laser with 1.1f.
That’s not to say that people can’t be hurt using my version, but if they know G-code, my version will function deterministically the way that the standard G-code commands work that they are used to using.
Case in point is this thread. My guess is that when Patrick loads in my version and does his M3 S(nnn) the laser will come on at that power level. You have to do more than that to get the laser turned on with version 1.1f. We’ll see. I think he is going to load my version.
That’s my take on it.
Here are the conditions for operating a laser with grbl version 1.1f and you can draw your own conclusions.