@achrn I ended up doing the output, and clicking all the links, and found a few more that weren't linking correctly: M3, M5, M17, M18, M292, M404, M558.2, M569.4, M586.4 and M606. All fixed now. Thanks for the reminder!

Ian

@achrn Thanks, I've updated that. Looks like it's been a loooong time since that section was looked at; at a quick glance there's other fields, and other uses of fields, that aren't listed there.

Ian

@meeloo it was an unfortunate breaking change when switching over from dozuki. The page names from the dozuki links are mostly still intact though, so a quick topic search on the new documentation should get you to the same place.

@droftarts - Ian, thanks for the clarification and additional info. I always learn something from this forum. Knowing that the endstops are ignored on all but H0 helps me understand more clearly how it works.

The more important thing I learned is that there can only be one end stop per motor and the design we are using does indeed have two NC endstop switches wired in series. We have recently been contemplating separating these to two inputs because in normal use, this motor is at rest with one of them triggered. In this situation, we can only know which end of travel we are at rest on by keeping track of it in sw - a risky proposition that a second input would eliminate. Now we know there will be additional macro work to do if we follow that path (re-define the endstop before making any moves). That'll be something for us to really look hard at.

@DonStauffer Thanks for that!

@droftarts ping for documentation update.

@DonStauffer It is a small bed, and kept leveled often, in many steps, so it has a good mesh file already, but thanks for the wishes, I know somebody who will be happy for them...

@rakupic Thanks, I have fixed the documentation generator. It should be "Millsecond fraction of upTime", the generator tool didn't process <see cref="..." /> links correctly.

fans[].thermostatic.heaters[] is valid in RRF 3.4 but deprecated in 3.5. I expect it to be removed in v3.6.

@Johnnyg note that updating LEDs connected to the dedicated LED output (Duet 3 only) does not suspend motion. If you are using Duet 2 or another pin on Duet 3, motion will be suspended while the LEDs update. See https://docs.duet3d.com/en/User_manual/Connecting_hardware/IO_Neopixel_DotStar#connections

Are you updating all LEDs with one command, or each LED separately with 30 M150 commands?

Ian

@Exerqtor

I have updated the documentation to cover this, thanks! This was a small revision to v1.2 to bring in the changes that we made for version 1.3, other than the mounting hole changes.

Provided a path to ground, via 100K resistors from the mounting holes to make it easier for static charge build up on the if the Toolboard is mounted on the Hemera XS Changed to higher power protection resistors for the thermistor inputs to better resist ESD/short from thermistor to 24V. Changed the circuit around the VSSA fuse to make it more robust to ESD events.

@T3P3Tony

Excellent, thank you!

@chrishamm Thanks; yes doing this just in Markdown is not really an option.

However; maybe this just makes it a more general request about the overall layout of the wiki pages; eg; detach scrolling of the navigation panel and decoration from the main page body. It's a petty request anyway. just floating ideas.

And you are also right about the plugin, and I've used the DWC OM browser extensively in my latest project; it is the best reference by far.
..But it requires my machine to actually be switched on and connected to WiFi. This is not always true, especially when I'm coding while on the road (although I have a ssh proxy/tunnel into my network, I just prefer the machine to be off when I'm not about).

@dc42 I realise now I wasn't actually checking the tools array like that, I was checking a global vector storing additional tool details { vector(limits.tools, {radius, {deflection-x, deflection-y}}) } which is linked to the defined tool, so the existing fix should cover all of my usages. Thanks!

@timschneider Interesting, as that section has been in the Gcode dictionary since September 2022, and barely edited since! I'll update it with what @dc42 sent me earlier.

EDIT: Okay, I've updated this section, I think it makes sense: https://docs.duet3d.com/en/User_manual/Reference/Gcodes#command-queueing

Ian

@paralepsis documentation of the object limits is a good idea, one for @droftarts

@oliof I have updated these pages with info on connecting SZP and accelerometer, and written the SZP calibration page:
https://docs.duet3d.com/en/Duet3D_hardware/Duet_3_family/Duet_3_Scanning_Z_Probe
https://docs.duet3d.com/en/Duet3D_hardware/Duet_3_family/Duet_3_Roto_Toolboard
https://docs.duet3d.com/User_manual/Tuning/scanning_z_probe_calibration

I'll check them when I get an SZP and Roto, hopefully early next week.

Ian

@OwenD In RRF too????? Noooooooooooooooooooooooooooooo jajajajaja
Thanks all for the clarification

@appjaws
Hi - I'm curious as to your use-case. Is your need to have the backups on your windows computer for occasional use? e.g. restore / write to an SD card. Or do you have some other use-case.

Part of the reason I ask is that I am the author of the duetBackup plugin and curious if I need / should add additional functionality.

@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

Thanks @droftarts. 1Khz is high enough for my use case. I wanted to measure the power of my Revo 40W and higher PWM frequencies makes it easier with the RMS to DC integration.

BTW, in my system, with 24V supply, Duet Min 5+, and Revo 40W, the average power during the 100% PWM phase of warming to 245C, is only 25.5W. This is due to the intentional increase of resistance with temperature (PTC).

1b585080-2341-42c4-8140-4e46a55979eb-image.png