Laser power not sticking between G1 commands?
-
@dc42 said in Laser power not sticking between G1 commands?:
The laser should stay on for further G1 moves, however a G0 move is by definition a travel move so it will turn the laser off.
Firmware 2.02RC3 supports the S parameter, if you configure the machine as a laser cutter. You have to use the H parameter to designate special G1 moves instead of S.
So on G0 move it will turn off and the next G1 move will not turn it back on? Not sure if this should work like this. And sure, I can add to all moves S parameter, but I still think that g-code with I posted schould work too.
About the H parameter, not sure what you mean. But I edited already all my config files so they use H parameter.
EDIT
And I use firmware 2.02RC2, I will check if RC3 works better.
-
@dragonn said in Laser power not sticking between G1 commands?:
So on G0 move it will turn off and the next G1 move will not turn it back on?
Lasers are dangerous, so surely it would be unsafe to turn the laser on automatically again?
-
@dc42 said in Laser power not sticking between G1 commands?:
@dragonn said in Laser power not sticking between G1 commands?:
So on G0 move it will turn off and the next G1 move will not turn it back on?
Lasers are dangerous, so surely it would be unsafe to turn the laser on automatically again?
Yeah, sure but if that is a common implementation? Smoothieware does this, not sure if grbl does this too https://github.com/gnea/grbl/wiki/Grbl-v1.1-Laser-Mode but I think yes.
In other words, a G0 rapid motion mode or G38.x probe cycle will never turn on and always disable the laser, but will still update the running modal state. When changed to a G1 G2 G3 modal state, Grbl will immediately enable the laser based on the current running state.
Not sure it I understand this right, but this sounds for me like it would enable the laser back on.
-
My background is in safety engineering, and I really think that someone needs to take this up with the writers of software used to generate GCode for laser cutters. It seems to me to be highly unsafe to leave a laser turned on. It's an accident waiting to happen, sooner or later someone is going to get burned or blinded when the laser turns on unexpectedly. The GCode generators should be written to turn the laser on whenever it is needed, so the firmware can default to the laser being off.
-
I agree with you, and is not a problem for my to just edit the g-code before running it.
About safety, I never use my laser at the full power mode (it has a switch for that) when I am in the room where my printer is. When I want to do engraving I turn my printer remotely on and watch it over a webcam.
Just wonted to know if that behavior is intended. -
I guess I could add an "Unsafe mode" option to the M452 command.
Where can I find the support forums for the laser cutter GCode generators, where it would be appropriate for me to request changes in the interests of safety?
-
Not sure, I am quite new to laser engraver software, but for VisiCut this would be only a meter of writing a new driver https://github.com/t-oster/VisiCut/wiki/Developing-a-new-Lasercutter-Driver
-
Oh, it sems like VisiCut can add S to all moves, I did setup it wrong. But it addes S0.00000 and for example S1.00000, does Duet support non int numbers at S parameter?
-
@dragonn said in Laser power not sticking between G1 commands?:
Oh, it sems like VisiCut can add S to all moves, I did setup it wrong. But it addes S0.00000 and for example S1.00000, does Duet support non int numbers at S parameter?
Yes. You can configure the S value that means full power.
-
I must say, VisiCut works really well with Duet, amazing result -
Hi, can you share your VisiCut config?