Homing followed by tool change crashes endstops

[hernejj]

The following Gcode causes my Makerfarm i3v Prusa variant (which homes to 0,0 in the far right corner) to attempt to reposition the 2nd toolhead (T1) over coordinates 0,0. Since the machine was just homed and it resting on the endstops, the resulting x-direction move to -27 (my T1 x-offset is 27) causes a potentially damaging crash of the x-carriage into the x-endstop.

G28 X Y
T1

I suspect there should be some logic in Marlin to prevent this? Perhaps related to min_software_endstops?

I am running RCBugFix as of Fri May 20 14:50:49, my head commit is 2f6e7b7.

[hofcake]

Doesn't the extruder move away from the endstop before returning to home?

[hernejj]

@jamiehofer If you are referring to the movement of the extruder during the G28 command then I believe so yes. However, my issue is on the T1 command. That is when the extruder tries to go negative.

I've looked at the code and I see the following call chain:
gcode_T()
prepare_move()
clamp_to_software_endstops()

Which should prevent this under run from happening. But it most definitely happened. I'll keep looking at it.

[hofcake]

Was it restarted between the G27 and T1?

[hofcake]

G28 sorry, on mobile.

[hernejj]

Nothing was restarted. The two commands were issued back to back by hand from Octoprint's gcode terminal.

I should probably mention the G28 was actually the following
G28 X Y

[thinkyhead]

That's an important constraint, and sounds like it's in need of a comprehensive fix. The machine should simply prevent the movement from user perspective, but internally, when you swap extruders the software endstops might need an adjustment instead, which accomplishes the same thing, if done before the clamp function is called. I believe that's how we deal with dual X carriages currently. Anyway, I will make a patch shortly.

[AnHardt]

@thinkyhead
While you are in the software endstops anyway - how about shifting all that calculations, done for every move in clamp_to_software_endstops() to update_software_endstops()

    float negative_z_offset = 0;
    #if ENABLED(AUTO_BED_LEVELING_FEATURE)
      if (zprobe_zoffset < 0) negative_z_offset += zprobe_zoffset;
      if (home_offset[Z_AXIS] < 0) {
        #if ENABLED(DEBUG_LEVELING_FEATURE)
          if (DEBUGGING(LEVELING)) {
            SERIAL_ECHOPAIR("> clamp_to_software_endstops > Add home_offset[Z_AXIS]:", home_offset[Z_AXIS]);
            SERIAL_EOL;
          }
        #endif
        negative_z_offset += home_offset[Z_AXIS];
      }
    #endif
    NOLESS(target[Z_AXIS], sw_endstop_min[Z_AXIS] + negative_z_offset);

Some incomplete ideas in https://github.com/AnHardt/Marlin/tree/zprobe_offse--sw_endstop

[hernejj]

@thinkyhead The code looks like it SHOULD be clamping to me. Do you already know why it is not working in my case?

Clearly, something must be amiss, else I messed something up and reported a false bug twice in three days :`( I will reflash, reload default EPROM and recreate tonight just to be sure.

[thinkyhead]

@hernejj Well, the thing is that the code is doing a transparent "G92" operation, telling itself that the position has changed, but without then doing the compensatory changes to softtware endstops that have recently been applied to "G92." The problem is that after Marlin tells itself that the X carriage is (for example) farther to the right, the "move to previous position" operation tries to move back to the "current position" from the "new position" without properly updating the software endstops relative to the selected nozzle. So, PR #3829 should fix this issue.

[hernejj]

@thinkyhead Thank you :) I understand now.

[jbrazio]

Closing as patch submitted at #3829.

[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.