In the even that you have a job that contains multiple non-continuous paths. Should the G-CODE be M3 S0 or M5 eg. M3 S100 G1 [...] [...] G1 [...] M5 ; or M3 S0 ??? G1 [...] M3 S100 G1 [...] [...] G1 [...] M5
Oh it's M3 Sx G1 [...]; carve path [...] G1 [...] G1 S0 [...] ; move between path without carving G1 Sx [...] ; carve next path G1 [...] M5 ?
if you have laser mode enabled then G0 will never turn the laser on, only G1/2/3 moves will activate the laser which will be at the most recent Sxxx level. also, doing a G1 move when not cutting is very slow unless you also output a F feedrate for every move. this makes writing the code more complicated but also complicates reading it later to figure out why it did the wrong thing (-: KISS.
Snippet of an actual ngc file output from Fusion 360 (likely with some manual find/replace post-processing in N++) to run my (grbl-based) laser on some non-contiguous paths: X46.569 Y33.54 X47.865 Y34.533 X49.207 Y35.465 X50.59 Y36.333 X52.013 Y37.135 M5 G0 X50.192 Y36.75 G1 M3 S900 F2000 X50.342 Y37.135 X50.518 Y37.508 X50.719 Y37.869 X50.945 Y38.215 X51.194 Y38.544 X51.465 Y38.856 X51.756 Y39.148 X52.068 Y39.419 M5 G0 X54.454 Y37.023 G1 M3 S900 F2000 X54.076 Y36.685 X53.673 Y36.377 X53.246 Y36.103 X52.799 Y35.863 X52.334 Y35.659 X51.855 Y35.492 X51.364 Y35.363 X50.865 Y35.275 M5 G0 X47.809 Y34.727 G1 M3 S900 F2000 X48.12 Y34.972 X48.445 Y35.201 X48.78 Y35.412 X49.126 Y35.605 X49.482 Y35.781 X49.846 Y35.938 Edit: G0 rapids are at 10,000mm/min
Would work, but also not really what Grbl 1.1's laser mode set out to do. See gnea/grbl M3 or M4 at the start of the job to set the mode (standard or dynamic power. Dynamic preferred for most lasers) G0 = laser off move G1 Sx = laser on move M5 at the end of the job to disable laser active mode
Yep. I have laser mode turned off for testing and focusing, because it's pretty inconvenient. If/when I turn it on for production, the post-processing will change accordingly.
You can turn laser on and off in laser mode: On: OpenBuilds/OpenBuilds-CONTROL Off: OpenBuilds/OpenBuilds-CONTROL
So you're sending it the correct modal state- the G1F1M3S0000- without providing a coordinate move target, and it's turning the laser on whilst stationary? I suspected something like that should be possible, but the wiki isn't enormously clear on it and at the time it was easier just to turn $32 off, so I never went back to it. Certainly moves the "If/when" above firmly in the direction of "when" if I can just MDI grbl a static laser command by omitting XYZ without getting an error 26 in return.
wth, argument S isn't even valid for command M5 OpenBuilds/OpenBuilds-CONTROL At least according to rep rap wiki
grbl uses LinuxCNC standards, not sure if that affects anything. Since M5 and S0 effectively do the same thing, I imagine the reason to use both is that M5 is the modal command- puts the "spindle" into an unpowered state that will continue, even with a stray S command somewhere. The S0 prevents the laser from being reactivated in future at an unknown state. Seems like belt-and-bracers programming to me, which should be a good thing. On the other hand, a quote from the grbl wiki while I happen to be browsing it... Seems like the M3 command sans motion isn't allowed, so I'm not sure how OBCONTROL is managing it? Sounds like it should be forced to be an M4 command, but that's not what's in the code. Or is the "and in the middle of a job" actually a literal logical AND? Ie. you can use no axis words, but only at the beginning or end of a job. It's hard to tell.
S is a modal on its own, its parsed on its own, whenever it appears in a line with any other command We set both to turn off as safety (Set the M5 modal, but also set S to 0 (since its also modal) so a subsequent G1 moves doesnt turn on unless you intend to) Technically no, but... it works and is the only way to turn on the laser in laser mode. Its Claudio Prezzi who figured out that trick in LaserWeb4's days: LaserWeb/lw.comm-server M4 won't turn on on a G1 without a motion target (as it set power as a function of current feed) but M3 does, we do force it in OpenBuilds/OpenBuilds-CONTROL Especially lasers... some applications use G1/0 for jog still! (Havent embraced gnea/grbl the new Jogging mode either, we do) so setting it just for safety We just send it, Grbl takes it, and laser goes on
Oh and in reference to this: Thats why its only used for testing/focussing and not during actual motion. In motion we (and you should) rely on Laser Mode to do its things with G0=off, G1=on
Gotcha. I think that all makes sense. I actually decided to call my electronics cabinet for the laser done at last, so I should be able to power it back up again soon and test it (and probably update the firmware, I'm not sure what revision of 1.1/1.x it's actually on from the beginning of the year)
