First Z move should G0 not G1

[ghost]

Just like the first x & y moves to get the laser into position for an operation uses a G0, the same should be for the Z.

At the moment, the initial Z movement is a G1 which causes the laser to fire and burn.

; Pass 0
; Pass Z Height 7mm (Offset: 1mm)
G1 Z7.00
; Pass 0 Path 0
G0 X213.92 Y134.65
G1 X213.92 Y161.59 S0.50 F1000
---

[jorgerobles]

@DarklyLabs, done. Anyways I should advice to include always an explicit gcode (M3/M5) for any tool work. As separation of concerns, G1(movement) should not be firing the laser.

[ghost]

@jorgerobles G1 fires the laser in Smoothie.

[jorgerobles]

@DarklyLabs that's configurable :smile: http://smoothieware.org/switch#laser-power-supply

[tbfleming]

I don't like the term "separation of concerns"; web developers took a solid engineering principle and inverted its meaning, using it to justify a separation of technologies instead (.js, .html, .css). All of the bazillion js frameworks are attempts to undo the damage. None have succeeded to solve the problems that "separation of concerns" created.

G0/G1: I believe laser people made the right choice; it reflects well on how mills and lathes use these codes.

[ghost]

G1 fires the laser in all laser firmwares. That z move has to be G0 in laser mode as its actually repositioning the bed height. In mills Z has to be G1 as its a actual cut move to plunge into material.

On Mar 1, 2017 4:28 PM, "Todd Fleming" notifications@github.com wrote:

I don't like the term "separation of concerns"; web developers took a solid engineering principle and inverted its meaning, using it to justify a separation of technologies instead (.js, .html, .css). All of the bazillion js frameworks are attempts to undo the damage. None have succeeded to solve the problems that "separation of concerns" created.

G0/G1: I believe laser people made the right choice; it reflects well on how mills and lathes use these codes.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/179#issuecomment-283354322, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr22rrGCEmoyHyaX4i4NjDFM9dCZ_pks5rhYCggaJpZM4MPTo8 .

[jorgerobles]

Well then :smile: I was talking about the risk that means that a movement does other thing than movement. I prefer to explicitly turn a tool on off, that that tool runs whenever I'm doing other thing (like move) In GRBL if you don't enable the tool with M3, the laser won't light, at least in the firms I've got. I prefer it to get a blast. I'm no professional, nor many of maker movement are, so, better be cautious.

[FabCreator]

@jorgerobles it should not be firing anyway because of the M3 not being sent. however its better the initial z is seen as a rapid movement instead of a cut. I have not seen this issue before of firing because we have the M3 and M5 on the TH pin, but it now makes sense why sometimes we dont move to the 0,0,0 position at rapid move speeds :D

Also we have had to remove the M3 M5 from every line to start and end to make raster faster?

[jorgerobles]

@FabCreator I agree with that. Must be G0 because is a faster movement. What I'm not so sure is why a G1 (slow movement) should fire the laser :D In my tests, I use M3/M5 on start/end job or layer change. In a raster I light up at raster start and stop at raster end.

[FabCreator]

@tbfleming well i guess if we have M3 and M5 at the start and end, perhaps its before the initial z movement? Or you just mean this aint proper we need M3 and M5 all the time?

[ghost]

Because G0 by principle is a 'tool off' move and G1 is a 'tool on'. In smoothie single pin configs m3/m5 does nothing. Its one of those convebtions we just have to follow - cant argue it away

On Mar 1, 2017 5:01 PM, "FabCreator" notifications@github.com wrote:

@tbfleming https://github.com/tbfleming well i guess if we have M3 and M5 at the start and end, perhaps its before the initial z movement? Or you just mean this aint proper we need M3 and M5 all the time?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/179#issuecomment-283363682, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2w8OlkLVgMdJc5uTz5BtCbXAmjlRks5rhYhVgaJpZM4MPTo8 .

[jorgerobles]

@openhardwarecoza That is then. I will not mess around anymore :D

[FabCreator]

@openhardwarecoza you saying G1 triggers the fire pin as well by default now?

[ghost]

If S was something other than 0 (and remember if S isnt specified somewhere earlier yet it defaults to 0.8), then G1 will output PWM into PWM pin. On the K40s a lot of users have JUST the PWM pin wired to the laser PSU. So NO m3/m5 safety. Therefore a G1 Z move will probably have beam on during that move (burning a dot where the head is while Z is changing)

On Grbl there is also only one pin, but the behaviour of the PWM pin is disabled/enabled with M3/M4/M5

On Smoothieware M3/m5 is in the SWITCH module, not the Laser Module. Users with just a laser module... will have a dangerous problem

[FabCreator]

O so most users have the laser "armed" constantly? That is not very wise indeed.

Just been checking our config and i notice the machine turns on with M3 enabled will need to change that.

[tbfleming]

@FabCreator K40 has a physical switch to arm/disarm.

[FabCreator]

@tbfleming i guess that helps :D but still no interlocks :O

[cprezzi]

Doesn't it work if you just place a M3S0 in the start commands?