Laser/ CNC Support in RRF - gCode Semantics

dc42

This is what I am thinking of implementing:

Add an extra parameter letter to G1 commands with the same meaning as S currently has. Possibly H, because S1 or H1 indicates a Homing move. This letter would be supported in all modes.
When M452 is used to set the machine to Laser mode, if the M452 command includes the S parameter then the meaning of S in G1 commands changes to laser power.
For G0 commands, the laser power will always be zero and any S parameter will be ignored.
A G1 command with no S parameter will be executed with the laser power set according to the most recent M3 command.
The number that follows the S parameter in the M452 command is the S value in G1 commands that corresponds to full power.

Comments?

Djen

Yes, that sounds like a great implementation! I'm really looking forward to this feature! It will make laser mode a lot more powerful and versatile! And using S as the parameter will ensure compatibility with most laser engraver software out there.

I'm really glad you're working on this! Thanks!

resam

All 5 points sound good for my use cases and also make sense in general I suppose!
Looking forward to testing it!

raykholo

@dc42

I like it.
This is certainly one of several reasonable ways to handle it.
Perfect.
Important point here: when we have G1 X10 F600 S0.8 followed by G1 X20, the second command would operate at the same feed and power value. Both feedrate and the laser power aka "spindle speed" must be modal. This is important because in the gCode we are working with there are no M3/ M5's at all, just G0 and G1 lines. From a cursory reading, I am not sure if conflicts might arise from listening to both M3 S values and G1 S values. Thoughts?
This certainly extends flexibility and might even solve the concern of compatibility with legacy control softwares.

dc42

@raykholo said in Laser/ CNC Support in RRF - gCode Semantics:

@dc42

I like it.

This is certainly one of several reasonable ways to handle it.

Perfect.

Important point here: when we have G1 X10 F600 S0.8 followed by G1 X20, the second command would operate at the same feed and power value. Both feedrate and the laser power aka "spindle speed" must be modal. This is important because in the gCode we are working with there are no M3/ M5's at all, just G0 and G1 lines. From a cursory reading, I am not sure if conflicts might arise from listening to both M3 S values and G1 S values. Thoughts?

This certainly extends flexibility and might even solve the concern of compatibility with legacy control softwares.

Regarding #4, can you confirm that Marlin, Smoothieware and grbl all carry over the S value from one G1 command to the next as you describe? In which case the S parameter on a G1 command behaves exactly the same as a M3 command before that G1 command would.

raykholo

@dc42

Regarding #4, can you confirm that Marlin, Smoothieware and grbl all carry over the S value from one G1 command to the next as you describe? In which case the S parameter on a G1 command behaves exactly the same as a M3 command before that G1 command would.

To the best of my knowledge Marlin does not do G1 X10 S0.6, it does not even discern between G0 and G1. So in Marlin M106 S255 followed by a number of G0/ G1 move commands would all abide by that power until another M106 was called.

In Smoothie and Grbl, the S does indeed carry over as from my example of G1 X10 F600 S0.8 followed by G1 X20, the second command would operate at the same feed and power value.

Smoothie and GRBL differ regarding M3 and I am concerned that neither of them is what it sounds like you are describing.
In Smoothie, M3 has nothing to do with laser. It is simply yet another gcode that can be configured to control a switch or a spindle module.... But if you simply send a G1 X10 F600 S0.8 the laser will run, no previous M3 required. But we put an M3 at the start of the job to be safe, and an M5 at the end.

In GRBL, please check here: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Laser-Mode

In short, it is a single M3/ M4 (per the link M4 is dynamic laser mode for better variable laser power) for better at the start of the job, and an M5 at the end of the job.

In no case do we want an M3 at the beginning and M5 at the end of every G1 line, that would clutter the gcode.

Bonne

Hi new to the Duet forum, I make CO2 laser cutter so excited to hear duet is moving towards lasers too

Currently we use the smoothieboard and Smoothie ware,
G0 is used for movements, G1 is used for movements with laser on.
The S value remains as default until a new one is assigned. Same goes for the Feed rate F.
For smoothie many uses don't bother with M3/M5, however we use them as laser enable/disable.
All smoothie movements are dynamic and adjusts the power to reflect the current speed, this helps provide very clean cuts. Most lasers have burnt corners because they are unable to lower the power when decelerating thus do not maintain an even power/mm2. This feature I would say is a must for good vector cutting and engraving.

Example code:
; Pass 0 Path 1
G0 X178.08 Y293.86
G1 X184.19 Y293.86 S1.00 F420
G1 X184.19 Y313.97
G1 X178.08 Y313.97
G1 X178.08 Y293.86

; Pass 0 Path 2
G0 X204.19 Y293.86
G1 X210.29 Y293.86 S0.50 F600
G1 X210.29 Y313.97
G1 X204.19 Y313.97
G1 X204.19 Y293.86

When it comes to raster engraving, . GRBL LPC I think is the fastest currently because it can turn of the dynamic planning. Currently they all work by sending lots of g code, each pulse is a line with a new S value to create the grey scale image. Smoothie begins to jitter at around 80mm/s, GRBL-LPC around 300mm/s.

Kind regards,
Bonne

dc42

Thanks for the input. Should the laser power during acceleration and deceleration be proportional to the speed, or is the relationship more complicated than that?

raykholo

@dc42

Smoothieware gives the cleanest corners when cutting we have seen. To the best of my knowledge it is handling the calculations for acceleration, deceleration, speed, and respective laser power pwm on each step generated.

The PWM rate is proportional to the speed, so the power to the tube is, but the CO2 tube doesn't respond in a linear way, so it's not perfect.

resam

@dc42 said in Laser/ CNC Support in RRF - gCode Semantics:

This is what I am thinking of implementing:

Add an extra parameter letter to G1 commands with the same meaning as S currently has. Possibly H, because S1 or H1 indicates a Homing move. This letter would be supported in all modes.

When M452 is used to set the machine to Laser mode, if the M452 command includes the S parameter then the meaning of S in G1 commands changes to laser power.

For G0 commands, the laser power will always be zero and any S parameter will be ignored.

A G1 command with no S parameter will be executed with the laser power set according to the most recent M3 command.

The number that follows the S parameter in the M452 command is the S value in G1 commands that corresponds to full power.

Comments?

@dc42 any progress on this? I didn't see anything about this in the 2.0RC's - is it going to make it, or do you target this for a possible future 2.1 release?

dc42

@resam said in Laser/ CNC Support in RRF - gCode Semantics:

@dc42 said in Laser/ CNC Support in RRF - gCode Semantics:

This is what I am thinking of implementing:

Add an extra parameter letter to G1 commands with the same meaning as S currently has. Possibly H, because S1 or H1 indicates a Homing move. This letter would be supported in all modes.

When M452 is used to set the machine to Laser mode, if the M452 command includes the S parameter then the meaning of S in G1 commands changes to laser power.

For G0 commands, the laser power will always be zero and any S parameter will be ignored.

A G1 command with no S parameter will be executed with the laser power set according to the most recent M3 command.

The number that follows the S parameter in the M452 command is the S value in G1 commands that corresponds to full power.

Comments?

@dc42 any progress on this? I didn't see anything about this in the 2.0RC's - is it going to make it, or do you target this for a possible future 2.1 release?

Firmware 2.0 is for the switch to RTOS and for bug fixes, so major enhancements like the laser support will have to wait for 2.01.