[2.0.x] Head goes to Z0 after toolchange with SWITCHING_NOZZLE and no_move==true

[marcio-ao]

Preconditions:

• Homing happens to Z_MAX
• SWITCHING_NOZZLE is enabled
• tool_change() is called with no_move=true

Example:

1. Power on printer
2. Home all axis
3. Press button on EXTENSIBLE_UI that calls "tool_change(1, 0, true)"
4. Printer moves to Z=0 before changing toolhead.

This regression was introduced by 6471a75 and it is caused by the following lines in toolchange.cpp:

      if (!no_move) {
         set_destination_from_current();
         ...
      }

      ...

      if (safe_to_move && !no_move && IsRunning()) {
         ...
      }
      #if ENABLED(SWITCHING_NOZZLE)
        else {
          // Move back down. (Including when the new tool is higher.)
          do_blocking_move_to_z(destination[Z_AXIS], planner.settings.max_feedrate_mm_s[Z_AXIS]);
        }
      #endif

When no_move=true and IsRunning()=false, then set_destination_from_current() never gets called, so do_blocking_move_to_z() sends the Z_AXIS to an uninitalized position.

The solution is to move the set_destination_from_current(); outside of the if (!no_move). I will create a PR for this fix.

[InsanityAutomation]

Thanks, I didn't get any response from a few requests for someone with a switching extruder to test that pr, as it was the biggest unknown. Only one I didn't have here to test!

I saw that tool head on the Taz 7 repo awhile back. Wish I had remembered in time to tag you while that pr sat open for feedback. Definitely going to be keeping an eye out for it to play with next year.

[thinkyhead]

Did the merged PR solve this definitively?

[InsanityAutomation]

I'll make sure to flash with this PR onto several other types of machines over the holiday weekend. I'm not sure I'll have a chance to get to it today or tomorrow as things stand.most likely switching extruder was affected because it was the only one that forced a Z raise regardless of no move condition.

[marcio-ao]

as things stand.most likely switching extruder was affected because it was the only one that forced a Z raise regardless of no move condition.

@InsanityAutomation: For what it is worth, we are developing a toolhead where the nozzles are driven up and down by two linear servos (one for each nozzle). So I actually have to modify the code to remove that Z raise and raise and lower the two servos instead.

Having the "force a Z raise" part be optional would better fit our needs.

[InsanityAutomation]

I did consider weather that was correct or not in working on that, however not having one myself I hesitated to make that change. Last I look at archim (iirc) it was a rack and pinion so it sounds like that's changed a bit as well!

[marcio-ao]

Yes, the rack and pinion was an early design which we experimented with. It had one servo and one stepper. It was a SWITCHING_EXTRUDER, in Marlin terminology.

But now we are using two linear servos that independently raise/lower the two hotends and steppers. This is based on the SWITCHING_NOZZLE in Marlin, but I had to modify the tool_change() code to remove the Z raise and to drive both servos in opposite directions (to lift one nozzle while dropping the other). You can see the code modifications I made via the link above, look for LULZBOT_SWITCHING_NOZZLE_OPPOSING_SERVOS and LULZBOT_SWITCHING_NOZZLE_NO_Z_LIFT

At this point, I wasn't planning to make a PR, but I could if there is an interest.

[InsanityAutomation]

Might be worthwhile to make a dual_servo_switching flag for switching nozzle that handles it this way as a standard. Regardless I still somewhat disagree with any movement on no_move and would prefer to see the set_destination block inside !no_move and the SWITCHING_NOZZLE branches in that area simply removed, allowing them to use the standard logic. In this case, the issue would still be resolved and may be more correct for your situation, since then you would just use the standard config variable and set it to 0. However I'd want some feedback from someone with an Ultimaker (I know, bad word to you!) or something to confirm as I don't know the history of the forced move.

[thinkyhead]

Anything actionable here, or are we just waiting for tool-change updates?

[marcio-ao]

@thinkyhead: Your merge solved the issue. I think this ticket could be closed. Some of the tool change things were just suggestions for possibly another thread.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.