Laser/ CNC Support in RRF - gCode Semantics

raykholo

Hi Folks,

We've been discussing how to better implement Laser (and CNC would be very similar) support in RepRapFirmware and would like to get your thoughts on a few gCode things:

The current sending approach I am seeing for setting laser power (interchange with spindle speed) in RRF is the "set the power of the fan with M106" so your gCode looks like this:

M106 S100
G1 X0.1
possibly M107, or if doing continuous raster line segments might be able to continue the raster line with another set of M106 and G1.

This most closely how Marlin does it.

Meanwhile, in Smoothie and Grbl, we can do:

G1 X0.1 S100 where S indicates a laser power range (Grbl is 0-1000, Smoothie is 0-1).

Given that the S parameter is used in almost all existing CNC and Laser driving software because S is the defacto designator for Spindle Speed… but RRF uses the S word to set endstop sensing...

We're down to 2 options I would like to present to you and get your opinions and vote on:

1. Use a different letter instead of S in the G1 line. Conveniently, L is available. So we could do G1 X0.1 L100 and any actively developed Laser/ CNC software could adjust/ make an RRF profile and all would be good, but any existing/ "legacy" software that is stuck outputting S would need to be post processed.

2. When the machine is put into Laser mode using M452, we would change the meaning of S in G1 moves to be laser PWM. So you would need to use the alternative parameter letter when doing special G1 moves in homing and tool change files. This allows legacy support and immediately supports more software out of the gate, but causes the concerns with S interfering with the homing scripts, and further potential overlap concern with a combo machine - either a 3DP/ Laser combined, or a multi toolhead machine like the new E3D announcement.

All thoughts welcome.

Thanks,
Ray

resam

I'm using laser mode M452 together with M3 and M5.
LaserWeb can be configured to output compatible gcode for this.
It works reasonably well - although I haven't done any extensive tests yet, only small/simple cutting passes.

T3P3Tony

I think this proposal would still allow M452 + M3 and M5 however it would make it easier for fast power switching for rasters

cgcafer

Hi resam,
i have problem by using LaserWeb 4.0.991. I am using M452 and M3 M5 command. Some laser On-Off doesn't work when i use "Laser Fill Path" strategy. So the result has a lot of missing lines.
Do you have same problem or have you any suggestion.

Note :I use Inkscape addin (J Tech Photonic Laser Tool) without any problem.
Thanks
Cafer

resam

I haven't tested this yet. But with the normal "laser cut" strategy I see some delay for laser turn-on (I believe). I ordered some electronics parts to invert my control signal (active-high vs. active-low). Once this is all done, I can do further tests.

DougJones

I have the same problem with missing lines and the firmware apparently missing M3 and M5 commands. I am also using laserweb, I have changed the laser web settings to add a delay and a second M3 or M5 command to the path start an d end gcode. It made a big difference to the missing infill lines.

dc42

The current system for synchronising other commands with movement commands doesn't allow for a large number of other commands to be queued. This may be the reason for the failure. When the queue becomes full, the oldest elements in it are executed immediately, so that happen earlier than you asked for. This could be what is happening.

I think we need to make laser power/spindle speed an exception from the normal queue mechanism and include it in the queue for the movement command, as we already do for the G1 P parameter.

Djen

I've been having the same problem with lots of consecutive M3/M5 commands not being queued properly. I'm trying to do raster engraving with a lot of fast switching so I'm frequently running over the buffer limit of 8 M-commands. I've been using G4 P1 at the end of each line to clear the buffer as a workaround but it's not very reliable.

Switching to a G1 parameter to control laser power would be ideal! Personally, I don't mind if it's S or L. Replacing the parameter in the gcode file is a matter of seconds in any text editor. Any estimate when this might be implemented? Or for the time being, is there an easy way to increase the buffer size for M-codes?

Danal

Hmmm.... shouldn't the laser power, no matter what the semantics of G-code to convey it, be "synched" like any other part of the move?

G0 X10Y20 is very different from G0 X10 G0 Y20. The first is a diagonal move, meaning it is a move where the X and Y speed vary in careful harmony with each other to arrive at point 10,20 at exactly the same time on the X and Y axis.

Shouldn't:

G0 X10Y10 L50
G0 X20Y30 L100

Shouldnt that second move vary the laser power smoothly so that it ramps from 50 to 100 in the exact same time as the diagonal move from 10,10 to 20,30? Meaning that X stepper, Y stepper, and Laser PWM all vary "in harmony" with each other?

Maybe that's just an assumed baseline in the above discussion. If so, I apologize.

Djen

@danal Well, the trouble is that the G0/G1 commands don't currently accept a L or S parameter to set laser power. It requires a separate M3/M5 command. And those are apparently handled in different queues which can cause them to be out of sync. Hence the initiative to introduce an L or S parameter in laser mode.
And no, typically the laser power isn't ramped up slowly over the course of a move. I honestly can't think of a scenario where that would be very useful. I would expect your example code to engrave two lines, each at constant laser power, the first at 50 and the second at 100, switching instantly between the two moves.

Danal

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

@danal Well, the trouble is that the G0/G1 commands don't currently accept a L or S parameter to set laser power. It requires a separate M3/M5 command. And those are apparently handled in different queues which can cause them to be out of sync. Hence the initiative to introduce an L or S parameter in laser mode.
And no, typically the laser power isn't ramped up slowly over the course of a move. I honestly can't think of a scenario where that would be very useful. I would expect your example code to engrave two lines, each at constant laser power, the first at 50 and the second at 100, switching instantly between the two moves.

Interesting. Thanks for the response.

I will be the first one to say that I know nothing about laser engraving/cutting. At the same time, the entirety of G-Code "works philosophically" that way. In fact, that is the difference between a G0 and a G1. G0 requires the motion controller to "coordinate" everything as it moves; G0 does not (with the note that Duet/RepRap chooses to treat a G1 like a G0).

And, crawling WAY out on a limb in my ignorance, I can see that would not be all that useful in cutting. However, it seems that it would be essential to engraving... ???

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.