Laser mode tweaks.

[chamnit]

ALL: Here are a list of tweaks I'm working on implementing prior to v1.1 master release! Please comment on them, if you disagree, have concerns, or think it's not the right thing to do for ANY reason. I'm fairly new to laser cutters and need user help to figure out some of the details.

• The laser will be automatically disabled whenever the motion mode is not G1, G2, or G3. This includes G0, G38.x, and G80 gcode commands. This is for safety reasons. I just got into laser cutters and it's very evident that safety is a huge issue with these devices. Fires are very easy to start.

• @DOUG888: In response to your earlier query. https://github.com/grbl/grbl/issues/1129 After much thought, I'm going to add laser disabling during a feed hold as the standard behavior.

• There will be two distinct laser cutting modes. Constant power and Dynamic power (acceleration ramp adjusted). They will be controlled by an M3 and M4 command, respectively. You would normally use M3 constant power mode, but in special cases, like finer detail jobs, M4 dynamic power mode can be used.

  • NOTE: The spindle direction pin will still behave the same way with M3 and M4. So it can be used with an LED to indicate which mode is active.

[swarfer]

Hiya I have no problem with your proposals, but I think I have found a bug... (found while changing SketchUcam to work with your first item above)

I have the latest code and

define LASER_CONSTANT_POWER_PER_RATE

and #32=1 and I have an LED connected to pin 11 (in place of the laser module I have not ordered yet ;)

Now I issue M3 S1000 and the LED stays off , as expected. G1 X100 F1000 and the LED fades up, then fades out again, as expected. G0 X0 and the LED flickers off/on at about 5Hz for the duration of the move, when it should stay off.

Does the same thing if #32=0 except that M3 S1000 will turn the LED full on, and motion will not fade in/out, but the flickering during G0 moves still happens.

Just recompiled with #define LASER_CONSTANT_POWER_PER_RATE undefined and the flickering is gone, as expected.

Thanks

[chamnit]

@swarfer: Thanks David. I'm aware of this issue and will issue a fix soon. I'll make sure it's fixed before going to master.

[Sylvan72]

Hello...

I send you my observations:

I am using the latest version 2016-11-04 with the laser module enable ($ 32 = 1), managed a 300 mW laser module.

• With #define LASER_CONSTANT_POWER_PER_RATE enabled, the laser never reaches 100% power (Spindle Maximun=255) even on long straight lines and with low speed and acceleration. I believe 100% power (S255) is expected as long as there is no acceleration or deceleration. I say this because the laser does not seem to have the same cutting power with active and inactive LASER_CONSTANT_POWER_PER_RATE.
• The laser remains enabled when the G-CODE is interrupted. I do not know if it is a firmware or GRBL Panel problem that does not reset the laser output.

Thank you.

[chamnit]

@Sylvan72 : Thanks.

• The most current version is 2016-11-12. I had made some PWM calculation corrections in this last commit.
• When g-code is interrupted can mean a lot of things, can you be more specific? I'm aware of some conditions where the laser is not disabled properly. I'm already working on addressing these things, but I first have to alter the laser behavior as described in the first post. So there may be a few revisions to go.

[Sylvan72]

Hi.

Thank you for your attention.

I have tested my CNC with a laser. When I execute a G-CODE file through the GRBL Panel and I am forced to stop it, the laser activates when I move the XY axes. This occurs either by giving the command "X10" or by the "X +" (jogging) button.

Even if you enter the command "M5" or "M5 S0" the laser remains enabled.

[Sylvan72]

Sorry for my english ... I'm using google translator.

[chamnit]

@Sylvan72 : I'm assuming that this is with the experimental CONSTANT_POWER_PER_RATE option enabled. I'm also aware of this issue. It should work without this option from what I can tell.

I haven't been able to test the laser modes until just recently, so please be patient. I'm working to get this fixed quickly and the right way. Once the fixes get pushed, please try testing it, if you have time. I'd like to work out all of the kinks before going to master. These laser mode details are holding things up.

[Sylvan72]

I can only praise and thank you for your efforts. For my part, you can expect all the patience you want.

I hope that you can achieve your goals.

Thank you so much.

Greetings from Brazil to you.

[alpharesearch]

Nice to see this progress on the laser implementation. Good Job!

[arkypita]

Strange behaviour on my setup with grbl 1.1

1) I am experiencing some behaviour of Sylvan72, using CONSTANT_POWER_PER_RATE and $32=0 Once powered ON, laser still remain powered also on G5, G5 S0, S0, $H, and G0 too. I could wait for better implementation, but i really like this feature and i hope to see it soon.

2) Using CONSTANT_POWER_PER_RATE and $32=1 my laser still remain switched off, always.

Please comment on them, if you disagree, have concerns, or think it's not the right thing to do for ANY reason. I'm fairly new to laser cutters and need user help to figure out some of the details.

For my 2 cent i can say that small power laser user usually need to manually focus their lens. To do that, they activate laser at a small power (like 10%) with a S command and laser holded on a fixed position (no movement) so they can focus the small dot.

[modified]

I read that it was just requested/suggested and inserted in "commit_log_v1.1.txt".

Based on LaserWeb dev feedback, only G1, G2, and G3 moves operate with constant laser power mode. Meaning that G0, G38.x, and $J jogging motions operate without it and will keep a constant power output. This was specifically requested as a way to focus the laser by keeping the laser on when not moving. Operationally, this shouldn’t alter how the laser mode operates.

Thumb up for me!

[arkypita]

ps. i also write my own GRBL interface for windows (yep, another one!) optimized for laser. It is developed in C# and it work with 0.9 and 1.1 grbl

Because of laser optimization, no Z axes computation is done in graphical previev, but gcode streamer has no problem with Z.

It could be downloaded from https://github.com/arkypita/LaserGRBL

It's a one week aged project, so it is very simple, but funcionally and stable.

[cprezzi]

@chamnit : Hi Sonny. A big thank you for all your effort in grbl. I love it!

I have experimented a lot with diode lasers, engraving parameters and different controllers. To get optimal greyscale resolution, we need to be able to tweek the pwm frequency for the laser. High PWM frequency means very short pulses, which works good for 3d engraving, but don't lead to good grayscale resolution. Low PWM frequency results in much better grayscale resolution (on wood). This makes absolute sense to me, as wood needs some time to get dark. The total energy over a certain time is the same with high and low frequency, but the result on wood is much different.

Do you think you could pack a $ setting into grbl for adjusting the PWM frequency?

[chamnit]

@cprezzi : I'm a little leery about adding another Grbl '$' setting because v1.1 is very close to a master release and if there is enough available flash space to add it. (Every byte is precious at this point).

There are a few ways to setup the PWM (fast PWM vs phase-correct PWM) each with different frequencies they like to run at. So, there may be too many options to have to support. If anything, I could do something along the lines of a boolean to set between two user-configured modes. These modes would need to be pre-set by the user in the config.h or cpu_map.h files.

But, no guarantees at this point. It may have to wait until a v1.2 revision.

[chamnit]

@cprezzi : Or the laser mode $32 setting could be a value to set between a handful of user-configured PWM frequencies. For example, $32=0 is laser mode disabled. $32>0 would be a particular laser mode.

[cprezzi]

It's a good idea to use the $32 setting for this. There is anyways only a few prescaler values to play with. Anything is better than nothing ;)

[chamnit]

v1.1e was pushed this last weekend. The laser feature updates are pretty much done and I'd like some feedback on how everything works. Here's summary of what ended up changing:

• Must be in G1, G2, G3 motion mode to enable laser. ($J jog should keep laser on if in these states prior to jogging, but forgot to check.) This is intended to be a safety feature and make laser motions explicit. In other words, no G0 rapids with lasers on.
• M3 is constant power mode. Always on at the programmed power, so it can be used for focusing.
• M4 is dynamic power mode that automatically adjusts laser power based on current speed relative to the programmed rate. Super nice, but may not work for all materials due to nonlinearities of how lasers work. Will only turn on laser while in motion.
• Fixed an issue where Grbl would pause and sync, when it shouldn't for laser motions. It should run much smoother and faster overall.

I also started a laser_mode.md document in the /doc folder. I'll be adding more information on the new laser mode there. So, if you have any questions on the implementation, I'll make sure that it goes into that document. Thanks everyone!!

@cprezzi : Didn't forget about the PWM frequency request. May need to wait till v1.2, but I'll see what I can do.

[cprezzi]

I have jumped on v1.1e immediately when I saw it ;) Thank you so much for all your hard work! This finaly makes Grbl the favorite solution for lasercutters at the moment (in my opinion).

I will do more tests and let you know when I find some glitches :)

[chamnit]

Thanks! I'm embarrassed to say that I tried LaserWeb3 for the first time last night. It's a very nice piece of software. You guys did an incredible job on it. All of my test pieces came out great. I will not hesitate to recommend it to everyone in the future.

Another user sent me some g-code to test some vector etchings (not LW3 generated) with just M3 and M4 dynamic mode as the difference. It was tested with a 2.8W laser and a low-acceleration ShapeOko2. M4 looks quite nice and M3 has some noticeable extra burning where it accelerated near corners and small features. If a machine has high acceleration limits, both M3 and M4 should look nearly identical.

[arkypita]

I can confirm the improvement in laser engraving with M4 dynamic power mode, no more overburning in sharp direction changes. Well done @chamnit !

[mayhem2408]

I can also confirm M4 is working great. LaserWeb3 with variable feed and intensity produced an awesome result.

[chamnit]

@arkypita : Nice! Thanks for sharing and confirming. @mayhem2408 : 👍 Looks awesome!

[cprezzi]

I'm sure we will implement the M4 variant (switchable) into LW3, but because all the other firmwares are not capable of this, we need to allow that feature to Grbl > 1.1e only ;)

[alpharesearch]

To be honest it's a long time since I used my Shapeoko Laser/CNC machine. I have an older arduino (the one before the uno or actually a seeeduino clone V2.2) and I have to flash directly because I don't have the arduino bootloader and I think there were some size issues too. I was able to port all the configuration points from 0.9 to 1.1e and after flashing I reset all the eeprom. The good news is $H works like it did in the past and a G0 X5 moves the x axis for example. After that I try G1 X5 but I don't get an OK back instead error: 22 so I tried to look at the Interfacing with Grbl document but it looks like error numbers start with 23. I did try the Laserweb program and the serial monitor from arduino software to communicate with the machine and the result is the same. Any idea what I'm doing wrong?

PS: I guess I should have looked through the source and not the old wiki: "22","Undefined feed rate","Feed rate has not yet been set or is undefined."

[gerritv]

There is really excellent documentation for 1.1 here: https://github.com/gnea/grbl/tree/edge/doc/markdown Setting Feed rate for any movement command was made mandatory sometime ago.

[alpharesearch]

I did run my laser tests and everything works good. I was not able to see any issues so far. @chamnit I love the new M4 auto off feature and all the other safety parts are a great addition. There is a ton of new features since I last really used it (mostly V0.8 and little 0.9) and everything works great. @gerritv Thanks for the link to the new documentation, now I'm back up to speed.

[chamnit]

@alpharesearch : Awesome thanks for the feedback. At this point, I think v1.1 is ready for master release. I just have to clean up some code and documentation. Hopefully I can do that tomorrow.