Best posts made by Otso

Is the GCode documentation at https://docs.duet3d.com/en/User_manual/Reference/Gcodes generated from some other file, for example a "cleaner" XML file?

The reason I'm asking is that I would like to embed the documentation in a Duet control application I'm making. For example, the app has a command line and I want to show the relevant GCode command documentation when the users starts typing that GCode. I also want to filter out all GCodes that are not relevant for my use case (a CNC machine, so I don't for example need any documentation for GCodes that are strictly for 3D printing).

Of course I can scrape the web page, but it would be easier if there was a less cluttered source file that I could use.

Finally, some very subjective feedback on the web page: I find it annoying that the page scrolls to the location when clicking a GCode in the index on the left navigation bar instead of directly jumping to the location. This makes browsing the GCodes slower since you have to wait for the scrolling, and I also find it distracting. I don't see any benefit of the scrolling.

@oliof said in Enable laser without moving:

@chimaeragh you could even put macros called M3.g / M5.g into /sys ... add a parameter to M3 and you can control the PWM when calling M3. That said I see no reference to M3/M5 being disabled in RRF. Did you enable laser mode?

https://docs.duet3d.com/User_manual/Reference/Gcodes#m452-select-laser-device-mode:
"M3 and M5 no longer turn the laser on and off; use G1 Snn moves to control laser power."

Yes, this can be a pretty dangerous bug. I’m using firmware 3.4 and haven’t checked if it has been fixed.

I just tested with my laser and M42 S1 (no fraction) sets it at full power and not at 1/255 as one would expect from the documentation.

Either the code or the documentation needs to be fixed.

Personally I think this should be fixed in the code, especially if it is for backwards compatibility, where one can assume that “S1” previously set it at 1/255 of the power and since the introduction of fractions that changed it to full power.

With the firmware 3.4 implementation the documentation should say:

The S field may be in the range 0..1 or 2..255.

It should be noted that apparently values like 5.76 will probably also work, and be converted to 5.76/255. So the documentation could clarify that fractions are accepted, and the correct documentation would actually be:

The S field may be in the range [0,1] or ]1,255].

With further noting that the notation for the 1..255 range means any fractional value above, but not including, 1.

I'm making a desktop app to control the Duet 2 WiFi for CNC use (WorkBee). I do all communication over telnet, except for listing files on the SD card for which I use HTTP. The reason is that GET /rr_filelist returns the information in a convenient format. I know there is M20 S2, but that is not as convenient, since it doesn't return files size or creation time, so I would have to make an additional call with M36 to get the details (all I care about is file size and date). On top of that, I can't find a way to get directory create time with any G-code, as M36 on a directory gives an error.

My questions are:

• Is there a way to get the same information as GET /rr_filelist over telnet/G-code, in case I have missed it?
• If not, any plans to add it?
• Is there any way to get directory create time over telnet/G-code?

(Using a desktop app makes my workflow much easier, since no mouse clicking is needed, and I generally find usability to be better. This makes more of a difference for CNC use -- as opposed to 3D printing -- as you manually move the router around a lot more than with 3D printing, probing corners etc. My app is already usable, but still work in progress.)

@fcwilt said in Unclear interval in M42:

Question: where are you seeing this 0 to 254?

https://docs.duet3d.com/User_manual/Reference/Gcodes G1 documentation says:

RRF 3, G0/G1 S parameter AFTER M452 Laser Mode.
S parameter sets laser power with range of 0 to 254.

@kaguya Hi, you must add a newline character before the command will be processed. Try command = "M106 S128\n".

@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 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.

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?

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.