Marlin: ABL: moves off bed when using 2nd extruder

[hernejj]

When using the auto bed leveling feature and printing with the 2nd extruder (T1), Marlin attempts to move the extruder right off the far edge of the print bed on the first X,Y move operation of the print.

The Gcode to reproduce this bug:

G90 ; Abs positioning
G28 ; home all axes
G29 ; Abl Routine
G1 Z0.345 F120  ; Move z to first layer
T1
G1 X40 Y40 F300 ; This is the move that messes up

If I perform the same Gcode sequence without the G29, then everything works fine and I am able to execute a few G1 moves in x,y and z without issue. HOWEVER, When I run a real print, everything is fine up until the gcode tries a G1 to move to the 2nd layer of the print. When this happens the nozzle moves downward instead of up and crashes right into the bed. I am attaching the gcode file to this bug report.

NOTE: I am able to print just fine with extruder 1 (T0). Neither of the above problems are present in this case.

I am currently running RC5. I'd like to try RC6 but my Arduino IDE is not new enough. I'll try to get an updated Arduino IDE and report back if RC6 or perhaps the RCBugFix branch works any differently.

My printer is a MakerFarm i3v (Prusa i3 clone) that has been in service for a year on an older Marlin. I have run RC5 for about a month now with no issues before upgrading to dual extruders. I'll attach my current Configuration.h. Slicing software is Simplify3D. I'm using OctoPrint to feed Gcode to Marlin running on an Arduino/Ramps-1.4.

I'm happy to try things and report the results. I've looked at the code a bit and nothing immediately popped out at me. I tried adding some debug print lines to Planner.cpp : plan_buffer_line(). They looked like this:

//SERIAL_ECHO_START;
SERIAL_ECHOPGM("Delta-X: ");
SERIAL_ECHO(delta_mm[X_AXIS]);
SERIAL_ECHOPGM("Delta-Y: ");
SERIAL_ECHO(delta_mm[Y_AXIS]);
SERIAL_ECHOPGM("Delta-Z: ");
SERIAL_ECHO(delta_mm[Z_AXIS]);

But this caused Marlin to hang after the first G1 command. Is there another way to do a debug print?

[hernejj]

5mm_Calibration_StepsLEFT03.gcode.txt
Configuration.h.txt

[hernejj]

I just had the z head crash issue mentioned in the original report when using only the first extruder. It happened on the very first G1 move of the z axis. So this rules out any relation to toolhead selection.

I completed a 30 minute print with the first extruder without any problems yesterday. I'm not sure why It worked then and not now.

[hernejj]

I'm currently successfully printing the exact same gcode that caused the immediate head crash last night (no G29). I've changed nothing since then. I'm not sure what my results are so inconsistent.

I'm open to suggestions. Any ideas? :)

[thinkyhead]

and report back if RC6 or perhaps the RCBugFix branch works any differently…

Did you get a chance to try the current RCBugFix? It may work better, and it also should report the current position right after G28 and after G29, so we can see if something is amiss with the "current position" that could cause G29 to get confused and go to the wrong starting point.

[hernejj]

Thinkyhead, I just tried the first test gcode from my original report using the latest RCBugFix branch and it worked perfectly. I will perform some more extensive testing tonight and report back.

One thing I noticed is that the machine moved to place the second hot end at current position when I executed the T1 command. This was not happening on RC5. So I suspect this might be solved, but I'll run some real prints just to be sure.

Thanks for taking a look at my report and thanks to you and the rest of the Marlin devs for providing an awesome 3d printing firmware. This hobby would not be the same without it.

[hernejj]

I was able to complete two prints on RCBugFix without any issues whatsoever using extruder T1. I tried it with and without ABL. No trouble either way.

I think we can consider this one fixed. Sorry for not trying RCBugFix before opening the bug.