Don't apply hotend_offset.z to Z soft endstops

[zeleps]

Description

Setting the 2nd tool's z-offset to a positive value, results in the tool not being able to reach bed level. This is because zmin soft endstop is translated and the new endstop value for the tool becomes its z-offset. Since tools in a PARKING_EXTRUDER configuration are all carried on the X-axis, their nozzles' height difference must be compensated by moving the lowest tool lower than zmin, and zmin endstop value for all tools should be 0 (untranslated). This is typically not an issue, since tools are parked outside the hotbed area. If tools are parked within the bed area (in which case useful bed space is consumed, so not a typical configuration), they must be perfectly aligned in height in order to avoid the lowest tool from crashing on the bed.

This solution allows both tools reach the bed by skipping the change to the z-min soft endstop value (which typically happens on tool change). All other endstop values are translated accordingly.

E0 active:

___________X-AXIS__________
        |||             |||
        |||             |||
        |||              V
         V               
      ------BED-------
	  
E1 active, before the fix:

___________X-AXIS__________
|||                |||     
|||                |||     
|||                 V     
 V                       
      ------BED-------

E1 active after the fix:
	  
___________X-AXIS__________
|||                |||     
|||                |||     
|||                 V     
 V    ------BED-------

Benefits

2nd tools with a positive z-offset can work properly.

Configurations

Enable PARKING_EXTRUDER, create a 2nd extruder with a positive z-offset value.

Related Issues

This is complementary to pull request #20473

[zeleps]

Hm. Should have created a new branch instead of using the last pull request's. Hope that's not an issue...

[thinkyhead]

The only reason that apply_motion_limits is called from the tool-change function is to prevent a tool-change from causing the X axis to try to move outside the assumed bed area. I don't think we're worrying about the Z axis here, so it might be best to simply remove the call to apply_motion_limits and apply limits in a more liberal manner, maybe only worrying about the physical MIN/MAX boundaries instead of the soft limits.

[thinkyhead]

Should have created a new branch instead of using the last pull request's.

GitHub won't let you use the same branch for two open PRs at the same time, so it's not a worry. If you are concerned it might be out of date, just do a quick git fetch upstream ; git merge upstream/bugfix-2.0.x and you'll be back in sync.

[thinkyhead]

Meanwhile… I would advise generally that for tool-changing machines (and maybe all common machines) just disable MIN_SOFTWARE_ENDSTOP_Z or disable both MIN_SOFTWARE_ENDSTOPS and MAX_SOFTWARE_ENDSTOPS altogether. Who bloody needs 'em, right?

[thinkyhead]

Okay… After much rumination I think it's safe to go on the assumption that it's never a good idea to modify the Z soft endstops in response to a hotend offset. The current Z position should indeed be changed, but since we know hotend_offset.z has nothing to do with real constraints on motion, and we know it will be a very small number, it's most appropriate to just leave it untouched.

[zeleps]

Okay… After much rumination I think it's safe to go on the assumption that it's never a good idea to modify the Z soft endstops in response to a hotend offset. The current Z position should indeed be changed, but since we know hotend_offset.z has nothing to do with real constraints on motion, and we know it will be a very small number, it's most appropriate to just leave it untouched.

It seemed obvious to me when looking into it (why the hell would any tool need to translate zmin?), at least for cartesian machines, but I don't have much experience with tool changing (this is my first take on the subject) to imagine all the possible tool changing configurations and their specific intricacies. The zmax translation is still relevant though, in my configuration I've installed two hard stops on the z-axis to auto align it (MECHANICAL_GANTRY_CALIBRATION). The difference in height is of course negligible, but then again it's a difference (not that I'd perform the alignment with the 2nd gantry, but still it's a possibility).

[zeleps]

The soft endstops are meant to apply to the physical space that the physical machine can move around in safely. So if you have a setup which needs to be able to physically move the nozzle below the "tool-zero-relative" minimum Z endstop, then you must set your Z min endstop to a negative value with a magnitude large enough to allow for the free movement below the bed in that spatial context.

In other words, I'm not sure we want to skip modifying the Z min software endstop, since it is being applied correctly and the issue can be addressed simply by changing the configuration.

I tried that (negative zmin, -2) before applying my solution, and the result was -not surprisingly- bad, since the endstop value logically represents the probe's (bltouch in my case) trigger point during homing, both tools would stop 2mm from the bed and refused to go lower :) of course I could have changed my probe z-offset to a larger negative value (-.5 -> -2.5), but that would be just translating the whole z system 2mm lower, and my second tool would still not reach the bed. I think leaving soft_endstop.min[Z_AXIS] untranslated is the right way to go.

[InsanityAutomation]

We had a very similar discussion a long time ago, and the conclusion reached was to set the Z_MIN (-3 in my case) to the maximum potential positive offset as the safety, then to use the MANUAL_Z_HOME_POS value to set home to still be 0. The clamping in my opinion should be done to the positioning after the offset is applied for anything aside from 2 fixed nozzles (eg e3d chimera).

[zeleps]

Ok, I wasn't aware of MANUAL_Z_HOME_POS. I'll try it out and see how it works in my case.

[zeleps]

I just tested MANUAL_Z_HOME_POS. If I knew about it, I wouldn't have really gotten into the trouble of finding another solution to my problem, BUT it's not imho a proper solution. Moving Z_MIN_POS lower than the bed (i.e. -2mm) does not really prevent my tools from crashing on it, even if it is for 2mm. The proposed solution does, and it does it for the specific tool that is active at the moment. The other tools might actually crash on the bed, if they are not at their respective parking positions, but that's not a normal scenario. Typically, in a tool changing configuration, inactive tools are parked somewhere outside the bed area, so that's not an issue.

I think Z-axis configuration has become a bit more complicated than it should be. We have the Z_MIN_POS, which is a soft endstop, optionally MANUAL_Z_HOME_POS which is actually the position where the probe is activated (otherwise it's the Z_MIN_POS), NOZZLE_TO_PROBE_OFFSET[Z_AXIS] which is the offset of E0 from MANUAL_Z_HOME_POS and the HOTEND_OFFSET_Z matrix which is the offset of all other tools from E0. I feel that their significance, position in the configuration.h file and transitive relation, makes them more obscure and hard to configure than they should be. Typically I'd start with a baseline, which is the probing position (and should be named accordingly), have a different z-offset for each tool relative to the baseline (and not to each other), and optionally a software endstop, exclusively lower than the baseline, in case it's needed (for calibration purposes maybe?). Which brings up another major issue (I'm sure @thinkyhead has spent countless hours thinking about it), the tool-less state. Most toolchanging systems can be at a state that the toolhead has no tool attached. And that's a real state, that is not represented in any way in Marlin. There's always a tool selected, and that makes it hard to write code for operations that can and in some configurations should be tool-less, like bed levelling).

I'm just thinking loudly here, I know it's not the right place for this discussion.