Unclear interval in M42

gloomyandy

@Otso I've fixed the link to the code used for G1 S it is here: https://github.com/Duet3D/RepRapFirmware/blob/47435151e110f373fc80721a2c265e38b8ec5e3b/src/GCodes/GCodes.cpp#L4770

gloomyandy

@gloomyandy Oh and in case you are wondering laserMaxPower is set of M452 and defaults to 255.0

Otso

@gloomyandy said in Unclear interval in M42:

@Otso I've fixed the link to the code used for G1 S it is here: https://github.com/Duet3D/RepRapFirmware/blob/47435151e110f373fc80721a2c265e38b8ec5e3b/src/GCodes/GCodes.cpp#L4770

Thanks! I think I need to get to my computer to investigate the code more to figure where laserMaxPower is set, and what value it has in my case.

Pwm_t GCodes::ConvertLaserPwm(float reqVal) const noexcept
{
	return (uint16_t)constrain<long>(lrintf((reqVal * 65535)/laserMaxPower), 0, 65535);
}

Edit: Thanks for giving the info about laserMaxPower.

Otso

This post is deleted!

Otso

@fcwilt said in Unclear interval in M42:

Yes, in practice it works. After all how many times are folks going to specify a PWM value of 1 out of the range 0 to 255.

For example, if I use an application that converts a gray scale image to laser power, then some light pixels could map to 1 and cause the laser to blast out full power.

Or if you manually enable the laser at a very low level to set the laser focus or to line up the zero point. (I've been using S0.0001, but I could just as well have started with 1 and expecting it to be low power). Of course, you would notice the problem immediately and shut it down, but still, I don't like this I think it should be fixed.

gloomyandy

@Otso If you are converting from grey scale you should really be using G1 S, which I don't think has any of these issues.

gloomyandy

@Otso How do you propose fixing it without causing other problems with existing gcode/slicers/etc?

Otso

@gloomyandy said in Unclear interval in M42:

@gloomyandy Oh and in case you are wondering laserMaxPower is set of M452 and defaults to 255.0

Looking at the code for M452:

if (gb.Seen('R'))
{
    laserMaxPower = max<float>(1.0, gb.GetFValue());
}

I haven't tested, but based on that it seems like R is expected to be in the range 0..1 and defaults 1.0, which makes the formula for ConvertLaserPwm() make sense. If that's correct, the manual on M452 is wrong or misleading:

Rnnn The value of the S parameter in G1 commands that corresponds to full laser power, default 255

gloomyandy

@Otso I'm pretty sure the default is 255 (so the documentation is correct). If you specify a value with R it will be in the range 1 to whatever value you choose, that max function returns that largest value of 1 or your value, so in this case 1 is the minimum value you can set.

gloomyandy

@gloomyandy Going back to the problem with M42, remember it is used to control things other than laser output (it sets a general pwm level). I suppose a possible fix might be to add a parameter to the M950 used to create the pin and allow that to specify what the range is that will be used by M42. At least that's the best I can come up with that would probably still allow most things to work as they do today.

Otso

@gloomyandy said in Unclear interval in M42:

@Otso I'm pretty sure the default is 255 (so the documentation is correct). If you specify a value with R it will be in the range 1 to whatever value you choose, that max function returns that largest value of 1 or your value, so in this case 1 is the minimum value you can set.

Yes, you're totally correct, and so is the documentation. I wasn't thinking clearly.

Otso

@gloomyandy said in Unclear interval in M42:

@gloomyandy Going back to the problem with M42, remember it is used to control things other than laser output (it sets a general pwm level). I suppose a possible fix might be to add a parameter to the M950 used to create the pin and allow that to specify what the range is that will be used by M42. At least that's the best I can come up with that would probably still allow most things to work as they do today.

I'd expect it to work like @fcwilt assumed it worked (and I did too), and that the code would check if it is "1" or "1.", and make the decision based on that. I think that wouldn't break anything, and would retain best backwards compatibility because that was how "1" was interpreted before fractions were introduced, and I'd assume those using fractions now will use 1.0 for full width pulse.

The quick and simple fix would be to mention this is the manual, just as a caution if nothing else.

Otso

@gloomyandy said in Unclear interval in M42:

@Otso If you are converting from grey scale you should really be using G1 S, which I don't think has any of these issues.

You're right. I wrongly assumed the same issue would be with G1 S1. But that's not the case. The only potential issue if the other one I mentioned, but that would be less of a problem in practice if the operator takes proper care with the assumption that it can blast at full power regardless of what commands you feed it (by always wearing eye protection etc.) as one should.

So yes, I agree, not a big issue.

Otso

@gloomyandy said in Unclear interval in M42:

@Otso How do you propose fixing it without causing other problems with existing gcode/slicers/etc?

Just clarifying the documentation would be sufficient for me.

But like I said above, I think it already introduced potential problems when the meaning of value of "1" was changed with the introduction of fractions. But again, I'm not asking for a code change, just a documentation fix.

Otso

And the G1 documentation should be updated to say that the max value for S is defined by M452, which defaults to 255.

Otso

@gloomyandy said in Unclear interval in M42:

@Otso How do you propose fixing it without causing other problems with existing gcode/slicers/etc?

My snarky reply would be that you have the existing programs update accordingly, like I had to do in multiple places when M3 didn’t turn on the laser anymore. This affected both controlled moves and laser focusing/aligning. I still can’t understand why the support for that was removed as removing the support just removed it without adding anything that made it worthwhile, AFAIK. But’s that another topic, that doesn’t belong here.

droftarts

Thanks for highlighting this. I’ll check with @dc42 whether it’s a documentation and/or firmware change.

Ian

Otso

@droftarts said in Unclear interval in M42:

Thanks for highlighting this. I’ll check with @dc42 whether it’s a documentation and/or firmware change.

Ian

If you are referring to my sarcastic complaint about M3 , then I asked about it here quite some time ago:

https://forum.duet3d.com/topic/27718/enable-laser-without-moving

I.e, it was a deliberate firmware change for some reason and is documented in M543:

M3 and M5 no longer turn the laser on and off; use G1 Snn moves to control laser power.

droftarts

@Otso No, I was replying about M42 and G1 Sx ranges, the subject of the thread.
@T3P3Tony replied to me to say: "Documentation issues imo scale is 0-1 or 2-255 afair"
So I'll update the documentation with this, if everyone is happy with that wording.

From memory, and I am not involved with the discussions about Gcode changes generally, there were a couple of reasons for dropping M3 to control a laser cutter:

Safety: M3, M4 and M5 in the NIST Gcode specification are for controlling spindles. Laser cutter support was added subsequently, but not to the specification. In hybrid machines, there's just too much danger of turning on the laser when you meant to turn on the spindle, or vice versa. Removing the functionality was the safest thing to do, and for the odd occasion that you needed to fire the laser without a movement, you can use a manual override, or for more accurate timing, M42. You could even create your own M3.1.g Gcode (see https://docs.duet3d.com/User_manual/Reference/Gcodes#custom-gcodes) to mimic M3 laser functionality.
Performance: M3 worked okay for laser cutting, but not for engraving. Having two Gcode commands for each change of power filled the command queue quicker, and couldn't maintain higher speeds. Increasing the queue length helped a little, but there was a finite limit to that, too. Switching to G1 Sx improved speed considerably, and now raster clustering has finally been added in 3.5, engraving is at a par with other firmwares. G1 Sx effectively makes M3 redundant, and was supported by laser software (eg Lightburn) and other firmwares (eg Smoothieware) before we adopted it; it wasn't pushed by us. I don't know if other firmwares also removed firing the laser with M3, but I wouldn't be surprised if they did.

If the M3 functionality is particularly important to you, it is still available in RRF 2.x; it has not been retrospectively removed.

Ian

Otso

@droftarts Please update G1 documentation too to say that the max value for S is defined by M452, which defaults to 255.

I may continue the M3 discussion elsewhere.