@T3P3Tony I would suggest either removing or updating the 130mm dimension up the left side as well, as this dimension is in fact 129.5.

Splitting the proverbial hair, I know!

@davidjryan thanks, corekkted.

@sonderzug Hi I have the same cr touch and LC board, wiring is correct but it shows Error: "G30: Probe was not triggered during probing move." Can you send me full configuration?

@infiniteloop It was specifically how the GCode part of it interacted that I didn't understand. The HRP is explained, and the GCodes are named, but how they interact seems to be a weak point of the docs.

Thanks you, everyone! It's been very helpful and I think I have it worked out now.

So here's the end result, in case it helps any future enthusiast to have an example:
Bed.png
The measurements I used in this discussion were rounded versions of my real machine to make it easy to talk about; this image contains the real values. Here's the actual geometry and what I settled on for settings. I left M208 X0 Y0 and used the probe as HRP, which simplifies the probing issue, and using the primary nozzle seems like it complicates and confuses things when using the secondary. In theory, my 2 nozzles and probe are supposed to all have the same X coordinate, but I had to fine tune it so the 2 nozzles come out in the same place given the same G0 or G1 command, and in real life they aren't quite in a line.

Regarding bed leveling, it's my understanding that the probe points need not all be in exactly the same relation to their respective screws as one another - that the differences are compensated for in the math. I did the best I could on each one, but naturally the machine home prevents getting toward the front enough to be close to the front left probe point. and the fans are in the way on the right probe point. My leveling isn't actually all that repeatable, but I'm assuming that's my build material not being held down well enough (PEI 2mm).

Something like this?

https://forum.duet3d.com/topic/13194/dsf-extension-exec-on-mcode-was-shutdown-sbc

@PCR Thanks, I'm getting around to documenting the complexities of the Tool Distribution board. I just realised the other day that it's possible to support eight toolboards (and maybe even nine if you use the CAN_OUT RJ11 port) wired as stubs, on a single TDB! You can use either pair of pins on each Tool output for a stub, and have a separate stub connected to each pair. Then, of course, you could have more than one toolboard per stub...

And yes, the tool bypass jumper needs to be on for stubs to work.

Ian

@droftarts you are right, "elif" works as well - and is easier. Thanks!

But I would add the note nevertheless, in case someone relies on the input variable for something else.

@achrn sorry I thought you were referring to my quote.

@droftarts Thank you for following up.

Control of the command pipeline, for lack of the exact phrase, is a common thread in bugs. I don't know enough to even be dangerous with the code for the firmware, but I wonder if there's not a different approach for a future version that focuses on command flow control.

To my future me:

This works:

M568 P0 S250 A2 M116 M568 P0 S150 A2 M116

@jumpedwithbothfeet G92 won't do what you want.

@oliof Link to new version: Conditional G Code best practice.pdf

I'm discussing with @T3P3Tony how to best incorporate this in the wiki.

Ian

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