Z-Axis moves too fast for steppers after G29 Auto bed leveling

I use the new Marlin Firmware on my old Prusa and use Auto bed leveling. It's kind of working, just after the probing has been done at one point and the printhead wants to move on to the next location, it moves super fast upwards. Faster than my printer is able to move. So it skips a lot of steps. It has nothing to do with the current the steppers get, I tried turning them up, same problem.
Also the DEFAULT_MAX_FEEDRATE doesn't change this upward moving speed. I just could affect the downwards movement.
And it's not just fast, it's super fast

Maybe someone understand marlin deeper than me can help with this?

I home some one will reply, I have the same issue.

Edited 1 time(s). Last edit at 08/22/2014 12:48PM by ti-luc.

Just one have the same Problem, nobody else had it? Nobody has a solution for us?
Plz, I'm so near to print again, just this little issue

Have you tried lowering HOMING_FEEDRATE? Warning - it's in mm per minute.

If that doesn't work, I've had a look at the source code and it seems the move is in a subroutine called do_blocking_move_to, which relies on the XY_TRAVEL_SPEED constant set in Configuration.h to determine the speed at which the probe will move in all axes, not just X and Y. Try lowering the value of this constant and see what effect it has on the Z move. It's in mm/min and defaults to 8000, which is 133.333 mm/sec and far too high for Z moves. A value of 4*60 (240) is safer, but will really slow down probe moves between sampling points.

---

[3DKarma.com] - suppliers of quality, affordable 3D printer kits and filament for the UK market.

Thanks for the answer

The HOMING_FEEDRATE does not affect the problem, but the XY_TRAVEL_SPEED does. Nevetheless it's not a real option to set XY Speed so low that the Z-axis does not stall anymore,because than XY movements get crazy slow.
Where did you find the do_blocking_move_to subroutine? Maybe we can tweak there a bit?

And the biggest question is, why it's just 2 people having this problem, when it's a problem in the code?


Edit: In Marlin_Main.cpp there is: --- feedrate = homing_feedrate[Z_AXIS]; --- in the G29 Case, doesn't this is supposed to set the speed for the z-axis movement?

Edited 1 time(s). Last edit at 08/24/2014 04:43AM by derletztename.

Maybe it's just a problem with the latest version of the firmware, combined with a relatively few number of people doing auto-levelling?

Line 1559 in Marlin_main.cpp sets the probe position for each of the bed levelling grid points by calling probe_pt. Lines 1552 and 1556 determine the Z axis position based on the values of Z_RAISE_BEFORE_PROBING and Z_RAISE_BETWEEN_PROBINGS respectively. NB: this is where AUTO_BED_LEVELING_GRID is defined. There's more code lower down to do the same where it isn't defined, but it does essentially the same thing also using probe_pt.

The subroutine probe_pt is only used within auto bed levelling and is defined at line 1033 of Marlin_main.cpp. It uses the subroutine do_blocking_move_to to move the hotend to a given set of coordinates and then controls the probe to get the bed height.

The subroutine do_blocking_move_to only seems to be used by probe_pt (it's also used in do_blocking_move_relative, but this doesn't seem to be used anywhere itself). do_blocking_move_to is defined at line 963 of Marlin_main.cpp and uses the XY_TRAVEL_SPEED constant to move the hotend to a given set of coordinates.

I don't have auto-levelling installed, but it should be possible to separate the x/y travel from the z travel and use different speeds for each. I'm unable to test it, but if you replace line 966 in Marlin_main.cpp, which reads as follows:

feedrate = XY_TRAVEL_SPEED;

with the following:

if(z == current_position[Z_AXIS])
feedrate = XY_TRAVEL_SPEED;
else
feedrate = homing_feedrate[Z_AXIS];

As probe_pt separates the Z and XY moves itself, this should do each move at the appropriate rate.

USE AT YOUR OWN RISK. I've compiled it, but as I said I can't test it as I don't have Z probing installed. Also be aware that the line numbers I've given here may be different to the version of Marlin you've got installed. I've got a very recent version, but can't guarantee it's the same as yours.

EDIT: This is a hack to see whether or not it's possible to achieve proper speed by axis of movement within z probing. It isn't something I'd recommend putting into the firmware for distribution. A more permanent change should include (optionally) sending the movement speed as a parameter to the do_blocking_move_to method, rather than assuming what speed to use within the method. I've posted this as it's a quick (but dirty) change.

Edited 1 time(s). Last edit at 08/24/2014 05:55AM by 3dkarma.

---

[3DKarma.com] - suppliers of quality, affordable 3D printer kits and filament for the UK market.

This actually was changed in the newer versions:

Old Version:

937.	static void do_blocking_move_to(float x, float y, float z) {
938.	float oldFeedRate = feedrate;
939.	
940.	feedrate = homing_feedrate[Z_AXIS];
941.	
942.	current_position[Z_AXIS] = z;
943.	plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
944.	st_synchronize();
945.	
946.	feedrate = XY_TRAVEL_SPEED;
947.	
948.	current_position[X_AXIS] = x;
949.	current_position[Y_AXIS] = y;
950.	plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
951.	st_synchronize();
952.	
953.	feedrate = oldFeedRate;
954.	}

New Version:

963.	static void do_blocking_move_to(float x, float y, float z) {
964.	    float oldFeedRate = feedrate;
965.	
966.	    feedrate = XY_TRAVEL_SPEED;
967.	
968.	    current_position[X_AXIS] = x;
969.	    current_position[Y_AXIS] = y;
970.	    current_position[Z_AXIS] = z;
971.	    plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
972.	    st_synchronize();
973.	
974.	    feedrate = oldFeedRate;
975.	}

Edit: I opened up an Issue at Marlin at Github for this

Edited 1 time(s). Last edit at 08/24/2014 06:13AM by derletztename.

That change would be the cause of the problem. The method probe_pt separates the z and x/y moves so it looks like do_blocking_move_to was changed as the separate moves in the latter .became redundant.

If we changed do_blocking_move_to to

static void do_blocking_move_to(float x, float y, float z, float movefeedrate = XY_TRAVEL_SPEED) {
    float oldFeedRate = feedrate;

    feedrate = movefeedrate;

    current_position[X_AXIS] = x;
    current_position[Y_AXIS] = y;
    current_position[Z_AXIS] = z;
    plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
    st_synchronize();

    feedrate = oldFeedRate;
}

And changed probe_pt so that the first line of code:

    do_blocking_move_to(current_position[X_AXIS], current_position[Y_AXIS], z_before);

becomes:

    do_blocking_move_to(current_position[X_AXIS], current_position[Y_AXIS], z_before, homing_feedrate[Z_AXIS]);

Then we get what we need with minimal impact. As before, USE WITH CAUTION. Compiles cleanly but untested.

EDIT: Thanks for raising the issue on GitHub, derletztename. I've added a comment with the above.

Edited 1 time(s). Last edit at 08/24/2014 06:47AM by 3dkarma.

---

[3DKarma.com] - suppliers of quality, affordable 3D printer kits and filament for the UK market.

I like your solution better than mine. Though mine does work, as I am using it now^^

Definitely stick with what works until they come out with a permanent fix.

---

[3DKarma.com] - suppliers of quality, affordable 3D printer kits and filament for the UK market.

I have been dealing with this challenge as well. I have been posting comments on the git ticket.
Git Ticket 1045

I changed the code as you suggested, and it did solve the problem during auto bed leveling. However when I attempt to print something, the problem shows up again when it is homing the z axis prior to printing. Any suggestions?

Quote
ibstrange1
I changed the code as you suggested, and it did solve the problem during auto bed leveling. However when I attempt to print something, the problem shows up again when it is homing the z axis prior to printing. Any suggestions?

Odd. the code change takes the HOMING_FEEDRATE value from Configuration.h, so Z homing should be slow enough. Try changing HOMING_FEEDRATE for the Z axis to something lower.

To find a good rate for your Z axis, you can use your printer control software (pronterface, repetier host, etc.) to get your Z axis moving at different speeds, to find one which works. First, home hour Z axis then send the following to the printer to move Z axis up 10mm at 180mm/minute, or 3 mm/second:

G1 F180
G1 Z10

You can fine-tune the speed in the first command to get the appropriate homing speed for your printer - just make sure you home between tests, or send G1 Z0 to home, or G1 Z10 to go up another 10mm.

---

[3DKarma.com] - suppliers of quality, affordable 3D printer kits and filament for the UK market.

Yep, that seemed to fix the problem, Thank you!

This did happen to me when I first started auto-leveling. My fix was to simply change my z axis max feedrate from 5 or so to 2.

Thank you so much!

Changing the code made it so that it didn't try to move too fast, but it also prevented the auto bed leveling from adjusting the z axis during a print, thereby making auto bed leveling useless. By reducing the maximum acceleration rate, the problem was solved, and auto bed leveling is functioning.

Changing the code made it so that it didn't try to move too fast, but it also prevented the auto bed leveling from adjusting the z axis during a print, thereby making auto bed leveling useless. By reducing the maximum acceleration rate, the problem was solved, and auto bed leveling is functioning.

Quote
derletztename
This actually was changed in the newer versions:

Old Version:

937.	static void do_blocking_move_to(float x, float y, float z) {
938.	float oldFeedRate = feedrate;
939.	
940.	feedrate = homing_feedrate[Z_AXIS];
941.	
942.	current_position[Z_AXIS] = z;
943.	plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
944.	st_synchronize();
945.	
946.	feedrate = XY_TRAVEL_SPEED;
947.	
948.	current_position[X_AXIS] = x;
949.	current_position[Y_AXIS] = y;
950.	plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
951.	st_synchronize();
952.	
953.	feedrate = oldFeedRate;
954.	}

New Version:

963.	static void do_blocking_move_to(float x, float y, float z) {
964.	    float oldFeedRate = feedrate;
965.	
966.	    feedrate = XY_TRAVEL_SPEED;
967.	
968.	    current_position[X_AXIS] = x;
969.	    current_position[Y_AXIS] = y;
970.	    current_position[Z_AXIS] = z;
971.	    plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
972.	    st_synchronize();
973.	
974.	    feedrate = oldFeedRate;
975.	}

Edit: I opened up an Issue at Marlin at Github for this

I have this problem too, and i know that this is a kinda old topic, but will i be able to copy/paste the old code into my firmware, and overwrite the new version and then the problem would be solved?

I have kinda solved it by setting xy travel speed to 150mm/min but its REALLY slow, so as i see it the old version could really help me out here..
I have overwrited it and i compiles fine, i just want to know if its safe to upload.