-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not require SOFTWARE_ENDSTOPS for dual extruders #15027
Conversation
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 |
@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…
…? |
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. |
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. |
That's the part I don't get - what if I both of:
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. |
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. |
7d7439d
to
7ad5208
Compare
53ba9bd
to
d63e0f6
Compare
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. |
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 |
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. |
Sensible approach to soft endstops before the machine is homed. Ref: #15027 (comment) Co-Authored-By: comps <comps@nomail.dom>
Sensible approach to soft endstops before the machine is homed. Ref: MarlinFirmware#15027 (comment) Co-Authored-By: comps <comps@nomail.dom>
Sensible approach to soft endstops before the machine is homed. Ref: MarlinFirmware#15027 (comment) Co-Authored-By: comps <comps@nomail.dom>
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: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 usingM211 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 disablingMIN_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 realHOTEND_OFFSET_*
? Can't the user just disable them withM211
anyway?