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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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.
-
And the G1 documentation should be updated to say that the max value for S is defined by M452, which defaults to 255.
-
@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. -
Thanks for highlighting this. I’ll check with @dc42 whether it’s a documentation and/or firmware change.
Ian
-
@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.
-
@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
-
@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.
-
@Otso @fcwilt @gloomyandy Thanks to this thread, I have updated various parts of the documentation:
G1 S parameter section is updated to include that max laser power is set by M452.
G1 S parameter range has been updated, which was 0..254, to 0-255.
G1 S parameter section now describes 'laser clustering', which was added in RRF 3.5.0-beta3.M42 and M106, where the range of values for PWM and fan settings is referred to, is now worded as follows:
The S field may be in the range 0.0-1.0 or >1.0-255. 0 is off in both cases.
I investigated M3 and M5 support (M4 has never been supported) in laser mode. M3 and M5 are still supported in laser mode, but in 'non-sticky' mode (M452 S0), they are redundant, as all G1 commands need an S parameter to fire the laser, otherwise it just defaults to S0. In 'sticky' mode (M452 S1), you can set the laser with, for example, M3 S255, then subsequent G1 moves will use that setting without needing an S parameter. M5 effectively sets G1 S0. M3/M5 can't be used to fire the laser on their own; the laser will only fire with a G1 movement command.
I will update M3, M4, M5, M452 in the Gcode dictionary, and https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_laser, with the above information.
Ian
