Do not require SOFTWARE_ENDSTOPS for dual extruders

[comps]

The problem with the sanity check introduced in #13386 is that it doesn't apply to just offset hotends, because HAS_HOTEND_OFFSET has nothing to do with offsets:

Marlin/src/inc/Conditionals_LCD.h:#define HAS_HOTEND_OFFSET (HOTENDS > 1)

The change from #13386 seems to prevent my dual-extruder printer from z-homing on a specific place while printing slightly below Z0. I can workaround that by disabling soft endstops using M211 S0, which seems to work, but a better "by default" fix would be more convenient.

I also tried to work around this by enabling MIN_SOFTWARE_ENDSTOPS, but disabling MIN_SOFTWARE_ENDSTOP_Z, which also seems to work and is closer to what I originally needed, but that doesn't IMHO make the sanity check any more justified.

Is there a good reason why we need software endstops for HOTENDS>1? Is there a good reason why we need them for real HOTEND_OFFSET_*? Can't the user just disable them with M211 anyway?

[thinkyhead]

HAS_HOTEND_OFFSET is what we use to determine that the hot-end offset is needed. And the only condition is more than one hot-end. Because of where it is, the full condition is actually:
(HOTENDS > 1) && DISABLED(DUAL_X_CARRIAGE)

The connection is that when we do a tool-change, the x-carriage may need to shift over to the position of the current nozzle (depending on the situation). Software endstops provide protection (or used to) so that the tool changes know what the current space limitations are, and won't try to move to an "illegal" position. The logic might have been updated to fall back to the X_(MIN|MAX)_POS values if soft endstops are disabled (or not compiled-in), which should be safe in all cases.

[thinkyhead]

@InsanityAutomation — Would you concur that the logic has been updated with recent tool change tweaks? And, do you think there is a bug that sneaked in which could…

prevent my dual-extruder printer from z-homing on a specific place while printing slightly below Z0

…?

[InsanityAutomation]

Yes, when we last discussed your recommended workaround was setting manual home to 0 and z_min to -3. On tool-change it was preventing the second head from lowering properly if the offset was below the first tool.

[thinkyhead]

Sounds about right. I'll see if we can add a warning about that, or otherwise make an exception for this situation. Or, we may want to prevent the second nozzle being allowed to be lower than the first, since the first is always used as the reference for the bed height.

[comps]

That's the part I don't get - what if I both of:

• don't care about software endstops and want them disabled
• don't have a hotend offset / all HOTEND_OFFSET_* commented out

why does the compilation still fail telling me that I need to enable hotend offsets?

This is the easiest "I don't want you to do anything hence you shouldn't need to check anything" case.

[InsanityAutomation]

I believe at one point we had discussed the possibility of using the probe low limit as the minimum for the second tool, which defaults to -2 mm.

As for stopping it from checking most things, multi nozzle is going to require those offsets at least be defined but you can leave them at zero if you don't want to use them. Software end stops can also be disabled lower in the configuration. if my memory is correct though there is still at least one or two places that uses values from the limits for motion even with soft end stops disabled.

[thinkyhead]

Looking into it a little more, the reason we have soft endstops required for any multi-nozzle setup is that we use the soft endstop values to constrain motion during tool-change so the tool head won't try to move outside the bed as it is moving into position. During printing, depending on the tool selected, the work boundaries will be shifted to the left or right, so we use the soft endstops feature to keep track of all these changes rather than writing a separate system of constraint. Consider that if you have two nozzles spaced 20mm apart, this reduces the bed width by 20mm. But we don't usually put that in the config as the bed size. So the "real" bed size comes from the soft endstops values combined with the hotend XY offsets.

So, that's the historical note. Simply turning off the requirement means also creating a substitute method to apply constraints. And now with editable XY hotend offsets just on the horizon, writing a substitute for soft endstops becomes even less tenable.

[comps]

So, that's the historical note. Simply turning off the requirement means also creating a substitute method to apply constraints. And now with editable XY hotend offsets just on the horizon, writing a substitute for soft endstops becomes even less tenable.

Well, my actual use case is jogging the machine around before homing, which essentially means I don't care whether soft endstops are enabled or used for toolchange moves, I just want G0/G1/G2/etc. moves generated by Pronterface/Octoprint to ignore them, so maybe we could leave them enabled as part of the core code, just toggle whether they come into effect for moves before the machine is homed.

(After homing, there is no benefit to having them disabled, given properly set dimensions.)

I could rewrite the sanity check to look for HOTEND_OFFSET_* being zero (I define the offset in Cura, like Lulzbot does), but - as you mentioned - there is M218 to change them on-the-fly, so that would be a bad idea.

[thinkyhead]

toggle whether they come into effect for moves before the machine is homed.

That is an interesting idea. On first blush I don't see any problem with the idea. In general soft endstops are not meaningful when the position is not known. We have the "not certain" state and we have the "not homed" state, which exists only once per session. So all we need is to check the homed state in the constrain method and that's it. The extra overhead will be minimal.