[1.1.x] Fix G1 behaviour after tool unpark

[orcinus]

Setup

• DUAL_X_CARRIAGE
• DXC_AUTO_PARK_MODE

Description

After every tool change, the first G1 that follows (whatever it is, even if not affecting X) results in the carriage going back to its X parking position very slowly, then the actual requested G1 move after that.

Reverting do_blocking_move_to back to prepare_move_to_destination in tool_change seems to completely fix the issue.

Benefits

Pre-fix:
https://www.youtube.com/watch?v=m4hY3lAxMaw

Post-fix:
https://www.youtube.com/watch?v=2RZavWEiwBY

Related Issues

Issue 2 from #10749

[GMagician]

@orcinus I think this will break SWITCHING_EXTRUDER SWITCHING_NOZZLE logic!
I suppose do_blocking_move_to was used to move xy before z: xy is repositionated then Z is re-lowered

[thinkyhead]

If the only issue is that destination is not being copied to current_position, then the correct solution is:

  do_blocking_move_to(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS]);
+ set_current_from_destination();

Please give that a try and report whether it works.

[orcinus]

Please give that a try and report whether it works.

Unfortunately, no, same behaviour as just do_blocking_move_to.

I could just wrap it in #if ENABLED(DUAL_X_CARRIAGE) ... #else or #if DISABLED(SWITCHING_NOZZLE) ... #else. Not a permanent solution, though, if the issue is elsewhere.

FWIW, prepare_move_to_destination() causes issues too, but only if doing a new tool_change before the unpark finishes. This will lead to completely messed up current position, and eventually one tool crashing into another. This scenario (two tool changes in a row) isn't very probable, though. If that becomes a problem, the tool_change state can be tracked via a new var (i don't think there is one currently), so one tool_change in progress blocks the next until finished.

[thinkyhead]

If the precise cause of the issue can be determined, that would be best. Here is a hint…

In a dual X carriage setup any G0 through G5 move is supposed to unpark the parked extruder before initiating the move.

The unpark logic is the most likely source of the strange slow move, and DEBUG_LEVELING_FEATURE plus M111 S32 will add extra debug messages to all these procedures. So please turn on this debugging and see what kind of output it gives.

If needed, we can add further debug output to track down the precise logical error.

[orcinus]

DEBUG_LEVELING_FEATURE won't compile with MBL, trying without it.

Edit: scratch that, it won't work with no BL, and i don't want to test with UBL as that already has problems of its own with tool_change so it will just muddy the waters further... Gonna see what's breaking with MBL and try and patch it up for testing purposes.

[orcinus]

Figured it out...
Turns out DEBUG_LEVELING_FEATURE needs to have ENABLE_LEVELING_FADE_HEIGHT or it fails on get_z function signature (three parameters vs. two).

[orcinus]

I think i've found the issue.
Commit coming soon.

[orcinus]

As it turns out, tool_change wasn't setting active_extruder_parked to false after unparking, causing the dual_x_carriage_unpark called from G0-G5 to attempt an unpark of an already unparked extruder.