Laser/ CNC Support in RRF - gCode Semantics

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.

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.